IPTEL WG - Minutes - IETF 55

IPTEL meeting minutes from the 55th IETF
Tuesday, November 19, 2002
1700-1800 Salon I

Chairs:
 J. Rosenberg <jdrosen@dynamicsoft.com>
 C. Jennings <fluffy@cisco.com>

---- Agenda ----

 - Status
 - TGREP issues
 - 2806 bis issues
 - Trunk Group issues
 - CPC/OLI issues (ran out of time and did not cover this)


---- Administrative Stuff ----

Cullen Jennings has joined Jonathan Rosenberg as a co-chair of the WG.  
There is a new mailing list, iptel@ietf.org. You can subscribe via email or 
at 
http://www.ietf.org/mailman/listinfo/iptel. People have not been 
automatically migrated as we could not get the list of subscribers on the 
old list.

The IESG has asked the working group to take on tel URI. We are likely to 
update the charter and schedule with more URI related items.


---- Status of current work items ----

TRIP MIB:

Expert review has been conducted which produced a revised version of the 
draft. There have been more comments since the revision on the list. We 
expect that one more reversion of this draft will likely have it ready for 
IESG. Working group last call was already completed once.

TGREP:

A new version of this draft has just been submitted. It is in need of 
expert review. It solves an important problem of preregistering a block of 
DNs for a gateway. It also provides resource availability 
information from a single gateway to devices making routing decision about 
which gateway to use.

New work:

The IESG has given the working group the mandate to take on telephony 
related URL items. This could include: 2806bis, 
draft-yu-tel-url, draft-ietf-iptel-trunk-group, 
draft-peterson-tel-cpc, draft-brandner-enum-uri. Also discussing 
draft-levin-iptel-h323-url-scheme (more on this later). When we have 
reached group consensus on what will be taken on and which document will 
adopted, the chairs will update the charter.


---- TGREP Presentation by Dhaval Shah -----

TGREP has been changed to be an auxiliary protocol instead of a subset of 
TRIP. Country codes have been added to the CIC.

Open Issue #1 - Thresholding Schemes. Leave them out of the draft or put in 
more detail? This is an detail implementation issue of a device that will 
effect how the TGREP protocol performs. There was some discussion of if 
this should be in a BCP but Jonathan pointed out that we don't have 
enough field experience to have any hope of knowing what the best 
practice is. After some discussion people seemed OK with not 
describing normative thresholding schemes in the draft.

Open Issue #2 - Is 128 bytes enough for the trunk group label. Jon 
Peterson though that 30 bytes would likely be enough so 128 should be 
fine. No other views expressed.

Open Issue #3 - Should carrier codes be ASCII or binary? A few people felt 
that ASCII would do fine. There were no objections to ASCII.

Jon Peterson had done a review and offered to send his comments to the 
list, most have already been incorporated into the current draft.

Chairs put in plea for comments on this draft so we do not have to assign 
reviewers. This draft seems close to being ready to go to the IESG.


---- 2806bis (tel URI) presentation by Henning Schulzrinne -----

This has undergone significant changes and is considerably narrowed in 
scope. URI comparisons should be case insensitive but 
implementation should use lower case letters. The BNF was cleaned up to 
remove order dependencies but a preferred ordering is specified. This 
draft is close to WGLC. The intent of the tel URI is to be an abstract 
address. It is not instructions on how to dial such that you reach a 
specific location.

Open Issue #1 - Context. Is a context needed for a number and if so how is 
this represented. The classic example is a 800 service number. Ways to 
represent a context include a DNS domain, a E.164 style prefix, or a list of 
prefixes.

Jon Peterson pointed out there are US 800 numbers that are scoped to bell 
operating companies, LATAs, countries, etc. Henning Schulzrinne said that he 
doesn't think it is realistic to generalize URIs to accommodate this.  Jon 
has been uncomfortable with the idea of context and added that the PSTN 
doesn't have this. For example, a phone number found piece of paper has no 
context and may not work if you were to arbitrarily use it. Henning 
explained some of the difficulties in using prefixes to express ranges of 
numbers.   Lawrence Conroy expressed that DNS is likely the "least bad" 
choice for how to do context but explained there could still be 
confusion on if the context ibm.com meant IBM's internal network or was an 
external context.

Jonathan pointed out that this context problem exits in other places such as 
an HTTP URL. The practical solution has been, if you find a URL, you can 
only use it in a context in which it is valid. Henning wanted us to 
consider the more radical step of not allowing local scope URI. (the U part 
of the URI.) Always having context would eliminate much of the 
silliness that happens today. He brought up the example of the problems 
that happened with the tv: URL. Jonathan leant more towards not 
providing context in the tel URI and just making sure that you did not send 
URLs out of scope.  This would still allow local scope.  Dave Oran 
pointed out that "speed dial" configuration was the same problem. Dave 
thought we should punt on trying to figure out if a given thing was in the 
scope or not. Flemming Andreasen thought it would be useful to have a 
context. Henning commented that in many cases, the tel URI was more like a 
URN than a URI. This is especially true for service numbers.

Jonathan argued this was not a tel URI specific problem and felt like a 
much bigger issue for someone else to solve. Jonathan said this draft is 
devoid of semantics on URI processing or any information on what you 
should do with one of these things. The meeting moved on to other topics but 
clearly this context topic needs more discussion on the list.

Open Issue #2 - Global numbers - are they global?

Global numbers are of the E.164 form. Some of them like 
+1-800-356-9733 look like global numbers but are not. It may not be 
possible to call them form many countries of states. [There has been 
significant discussion on the list since the meeting on this topic]

Next steps:

There was some short discussion on what it takes to get this to draft 
standard. One of the items needed with be an interoperability matrix.  
Henning would appreciate people contacting him if they have 
implemented tel URL.

Lawrence Conroy talked about how all of this changes the expect 
behavior of clients from the behavior in RFC 2806. These changes are not 
backwards compatible and will break existing systems. At least one system 
that is used for internal use only would be broken by this. It is not a 
requirement that this bis draft has to be backwards compatible but  the 
working group need to decide what we want to do.

Another issue that came up about going to draft standard is the 
question of the status of the normative references. Allison Mankin 
confirmed that all normative references need to be draft standards before 
this can go to draft standard. There is only one normative reference, RFC 
2396. There is a 2396bis in progress, and Jonathan will check as to 
whether this is going to draft standard or not.


---- Trunk Group presentation by Vijay Gurbani ----

The trunk group work has been motivated by the need to be able to 
indicate which of several different PSTN connections a single gateway 
should use for a given call.

Open Issue #1 - Should the trunk group indicator be carried in a SIP or tel 
URI? Right now it is in a tel URI.

Open Issue #2 - Should a trunk group label be in a local or global 
namespace?

Discussion centered around the proposed double equal sign syntax in the 
draft. Henning thought this did not look like a good idea but Rohan Mahy 
pointed out the list of legal choices was small. Please, anyone, propose 
something better on the list.

Open Issues #3 - How to represent both the originating and 
terminating trunk group in the same SIP message? The current proposal puts 
the terminating in the request URI and the originating in the Contact.

Jonathan brought up that there are no semantics for the tel URI but here we 
are bringing up semantics for SIP. If the tel URI is defined well 
enough, then there will be no need to do anything special for SIP. Dave 
Oran's comment on this was that Jonathan is underestimating the 
perversity of the implementers. There were no objections to the idea of SIP 
having a trunk group indicator in a Contact header field value or a 
request URI.

Open Issue #4 - Proxies should be able to change or add a 
destination trunk group to a request.


---- Items Moving Forward ----

Do we want to have a draft to extend the tel URI to include trunk 
groups?

Richard Shockey requested the ENUM URI work be moved to the IPTEL group.  We 
need to decide how/if we want to proceed with this.

The draft-zhao-iptel-gwloc-slp draft is solving a somewhat different 
problem than the TGREP and TRIP works so it will continue to proceed as an 
individual work.

Jon Peterson commended that he submitted the CPC draft for discussion only 
and he does not necessarily think it should be a charter item.

Orit Levin has been working hard an getting a draft documenting the H323 URL 
scheme. This was in the RFC editors queue but pulled back. Rohan brought up 
that this draft is entangled with the Annex O work for H.323. After some 
discussion it came up that one of the issues on this draft is if the WG or 
IETF can make any changes given that this is already in competed ITU 
specifications. Jonathan is going to discuss this with the ADs and Orit 
before deciding how we can move forward on this.


A more detailed version of the minutes was send to the list and is at 
http:
//www1.ietf.org/mail-archive/working-g
roups/iptel/current/msg00060.html Thank you Andrew for recording the 
minutes.