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

["Michael Hammer \(mhammer\)" <[e-mail]>]

Maybe I don't understand.  What is the difference between Table 1 and 2?
Table 2 appears to be a subset.  Why not just a single table?

Mike
 

> -----Original Message-----
> From: [e-mail] [mailto:[e-mail]] 
> On Behalf Of Vijay K. Gurbani
> Sent: Wednesday, February 08, 2006 5:18 PM
> To: Jonathan Rosenberg (jdrosen)
> Cc: IETF IPTEL WG; Cullen Jennings (fluffy)
> Subject: Re: [Iptel] Re: draft-ietf-iptel-tel-reg-00 submitted
> 
> (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
> [e-mail]
> https://www1.ietf.org/mailman/listinfo/iptel
> 

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