Subject: [Iptel] Nits review for trunk-group

From: "Vijay K. Gurbani" <[email-masked]>
Date: Tue, 29 Nov 2005 12:40:05 -0600

Folks:

During the nits review of trunk-group, the two points of feedback
were the lexicographic ordering of tel URI parameters and updating
the draft to reflect the newly created I-D on tel URI parameter
IANA registry.

Accordingly, I am proposing that the trunk-group I-D be modified
as described below (if you want to see this in the context of the
draft, please
see http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-trunk-group-05.html
or http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-trunk-group-05.txt).

I propose that Section 6 be modified as follows:

The ABNF will now look like:

     par = parameter / extension / isdn-subaddress / trunk-group /
           trunk-context

     trunk-group = ";tgrp=" trunk-group-label
     trunk-context = ";trunk-context=" descriptor

The following paragraph will be added:

    Trunk groups are identified by two parameters:  "tgrp" and "trunk-
    context"; both of these parameters MUST be present in a tel URI to
    identify a trunk group.  All implementations conforming to this
    specification MUST generate both of these parameters when using trunk
    groups.  If an implementation receives a tel URI with only one of the
    "tgrp" or "trunk-context" parameters, it MUST act as if there were
    not any trunk group identifiers present at all in that URI.  Whether
    or not to further process such an URI is up to the discretion of the
    implementation, however, if a decision is made to process it, the
    implementation must act as if there were not any trunk group
    identifiers present in the URI.

In addition, a historical note is to be added on the lexicographic
ordering of URI parameters as specified in rfc3261:

       Note that the base comparison rules for a sip or sips URI that has
       been derived from a tel URI mandate that the telephone-subscriber
       parameters be ordered lexically by parameter name (see Section
       19.1.6 of [3]).  Thus, when comparing a sip URI that has been
       derived from a tel URI, implementations MUST not assume that the
       "tgrp" and "trunk-context" parameters will appear in a consecutive
       manner because parameters defined by other tel URI extensions may
       lexically fit between "tgrp" and "trunk-context".

Section 9 (IANA considerations) be modified as follows:

    The IANA registry for tel URIs is specified in [5].  It is initially
    seeded with the two trunk group parameters contained in this
    specification.  For the sake of completeness, the IANA template for
    the two trunk group parameters is also specified below.

       Parameter name: tgrp
    ...
       Parameter name: trunk-context
    ...

I will be submitting the final document early next week.

Thanks,

- vijay
-- 
Vijay K. Gurbani, Ph.D.  vkg@{lucent.com,research.bell-labs.com,acm.org}
Lucent Technologies/Bell Laboratories, 2000 Lucent Lane, Rm 6G-440
Naperville, Illinois 60566     Voice: +1 630 224 0216
_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel