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-groups/iptel/current/msg00060.html
Thank you Andrew for recording the minutes.