Subject: Re: [Iptel] Re: draft-ietf-iptel-tel-reg-00 submitted

From: "Vijay K. Gurbani" <[email-masked]>
Date: Wed, 08 Feb 2006 16:18:19 -0600

(For a full text of Jonathan's comments, please see:
http://www1.ietf.org/mail-archive/web/iptel/current/msg01006.html)

On December 15, 2005 Jonathan Rosenberg wrote:
> Thanks for the quick turnaround on all this stuff, guys. Here are some 
> comments on the draft. A couple are more than just nits and may require 
> some discussion:

Jonathan: I am in the process of closing the work on this I-D.
Most of what you write below has been incorporated.  Please see
inline for the ones that require some discussions.

>> The tel URI parameter registry contains a column that indicates
>> whether or not each parameter only accepts a set of predefined
>> values.  The column can contain Yes, No, or NA.  Implementers of
>> parameters with a "yes" in that column need to find all the valid
>> parameter values in the RFCs provided as references.  Parameters that
>> are not allowed to have a parameters have a value of "NA".
> 
> 
> So, what does "No" mean? None of the entries in the registry are "No". I 
> originally thought No applied to parameters whose values were either 
> infinite in scope, or were a finite set, but from a set not defined 
> through enumeration (for example, the set of phone numbers). But, things 
> like isub are "Yes", so I'm confused.

Suggested modification

<MODIFICATION>
    Accordingly, the tel URI parameter registry contains a column that
    indicates whether or not each parameter only accepts a set of
    predefined values.  The column can contain "Yes", or "No".  A value
    of "Yes" in the column implies that certain predefined values exist
    for this parameter and the accompanying RFC should be consulted to
    find out the accepted set of values.  A value of "No" in the column
    implies that the parameter is used either as a flag, or does not have
    a set of predefined values.  The accompanying RFC should provide more
    information on the semantics of the parameter.

4.  IANA Considerations

    The specification creates a new IANA registry named "tel URI
    Parameters".

4.1  tel URI Parameters Registry

    New tel URI parameters and new values for existing URI parameters are
    registered by the IANA.  When registering a new tel parameter the
    following information MUST be provided.

    o  Name of the parameter.
    o  Whether the parameter only accepts a set of predefined values.
    o  Reference to the RFC defining the parameter and to any RFC that
       defines new values for the parameter.

    Table 1 contains the initial values for this registry.

    Parameter Name     Predefined Values     Reference
    --------------     -----------------     ---------
    isub               Yes                   [RFC 3966]
    ext                Yes                   [RFC 3966]
    phone-context      Yes                   [RFC 3966]
    enumdi             No                    [RFC AAAA]
    npdi               No                    [RFC BBBB]
    rn                 Yes                   [RFC BBBB]
    rn-context         Yes                   [RFC BBBB]
    cic                Yes                   [RFC BBBB]
    cic-context        Yes                   [RFC BBBB]
    tgrp               Yes                   [RFC CCCC]
    trunk-context      Yes                   [RFC CCCC]

    Table 1: IANA tel URI parameter registry
</MODIFICATION>

>> When registering a new tel parameter or a new value for a
>> parameter,
> 
> ..new value for an existing parameter...
> 
> Actually, I'd suggest a different template for registering a new 
> parameter vs. a new value for an existing parameter. In the former case, 
> you need everything you've listed. In the latter case, you only provide 
> the parameter name and the RFC number; you shouldn't provide a value for 
> the "predefined value" column. Indeed, you can only register new values 
> for parameters whose "preddefined value" columnb is "Yes", and the 
> instructions to IANA need to state that.

Suggested modifications:

<MODIFICATION>
    When registering a new value for an existing tel URI parameter, the
    following information MUST be provided:

    Parameter Name     Reference
    --------------     ---------

    Table 2: Registering an new value for an existing tel URI parameter

    Note to RFC Editor:  The token under the "Parameter Name" column in
    Table 2 MUST be present in one of the rows corresponding to the
    "Parameter Name" column in Table 1, and furthermore, that token MUST
    have a value of "Yes" in the corresponding "Predefined Values" column
    of Table 1.
</MODIFICATION>

>>  As per the terminology in RFC 2434 [3], the registration policy for
>>  tel URI parameters shall be "Specification Required".
> 
> Hmm. Thats not what the intro says. It says:
> 
> The tel URI parameters and values for these parameters MUST be
> documented in a standards-track RFC in order to be registered by
> IANA.
> 
[...]
> "specification required" allows for informational and experimental 
> documents. The text in the intro really seems to imply "standards 
> action", defined in RFC 2434 as:
> 
> Standards Action - Values are assigned only for Standards Track

Since most of the boilerplate stuff for IANA registry was lifted
from rfc3969, by that yardstick, even rfc3969 is in error.

In any case, for this I-D, I have changed the text to reflect
"Standards Action":

<MODIFICATION>

4.2  Registration Policy for tel URI Parameters

    As per the terminology in RFC 2434 [3], the registration policy for
    tel URI parameters shall be "Standards Action".  For the purposes of
    this registry, the parameter for which IANA registration is requested
    MUST be defined by a standards-track RFC.

</MODIFICATION>

Thanks.

- vijay

_______________________________________________
Iptel mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/iptel