Re: [Iptel] draft-ietf-iptel-reg-05

[lconroy <lconroy at insensate.co.uk>]

Hi Vijay, folks,
   Your/the IESG's solution is fine - it is even clearer, which is  
always good.
I look forward to seeing this as an RFC real soon now :).
all the best,
   Lawrence

On 16 May 2008, at 16:48, Vijay K. Gurbani wrote:
> Yu, James wrote:
>> Since the purpose of the I-D is to register "values" to avoid
>> duplicated assignments, any tel URI parameter that does not require
>> registration of predefined value(s) should be assigned "No" in Table
>> 1.
> [...]
>
> And Lawrence Conroy wrote:
>> Changing things now does not help, generates more work, and adds
>> precisely nothing - if someone isn't going to read the guidance text,
>> then chaning the logic of that text (and the table) isn't going to
>> help.
>
> James: By and large, I concur with Lawrence.  However, during the IESG
> review, there was a COMMENT raised to clarify the table contents a
> bit more.  Note that this was a COMMENT, and not a DISCUSS; so
> pedantically we could have left the table as-is; but I believe that
> addressing the COMMENT does do some good, and it may alleviate your
> problem as well.  The suggested -- and accepted -- text does not
> deviate from what is currently there in -05, just uses different
> words to render equivalent impact more cleanly.
>
> Here is the change that was agreed to:
>
> Section 3:
> OLD
>
>      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 or other permanent  
> and
>      readily available public specification 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 or other
>      permanent and readily available public specification should  
> provide
>      more information on the semantics of the parameter.
>
> NEW:
>
>      Accordingly, the tel URI parameter registry contains a column  
> that
>      indicates whether or not each parameter accepts a value.  The
>      column may contain "No value" or "Constrained".  A "Constrained"
>      in the column implies that certain predefined values exist for
>      this parameter and the accompanying RFC or other permanent and
>      readily available public specification should be consulted to  
> find
>      out the accepted set of values.  A "No Value" 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 or other
>      permanent and readily available public specification should  
> provide
>      more information on the semantics of the parameter.
>
> and accordingly, change the table as follows:
>
> OLD:
>
>      Parameter Name     Predefined Values     Reference
>      --------------     -----------------     ---------
>      isub               Yes                   [RFC 3966]
>      isub-encoding      Yes                   [RFC 4715]
>      ext                Yes                   [RFC 3966]
>      phone-context      Yes                   [RFC 3966]
>      enumdi             No                    [RFC 4759]
>      npdi               No                    [RFC 4694]
>      rn                 Yes                   [RFC 4694]
>      rn-context         Yes                   [RFC 4694]
>      cic                Yes                   [RFC 4694]
>      cic-context        Yes                   [RFC 4694]
>      tgrp               Yes                   [RFC 4904]
>      trunk-context      Yes                   [RFC 4904]
>
> NEW:
>
>      Parameter Name     Value Type      Reference
>      --------------     ------------    ---------
>      isub               Constrained     [RFC 3966]
>      isub-encoding      Constrained     [RFC 4715]
>      ext                Constrained     [RFC 3966]
>      phone-context      Constrained     [RFC 3966]
>      enumdi             No value        [RFC 4759]
>      npdi               No value        [RFC 4694]
>      rn                 Constrained     [RFC 4694]
>      rn-context         Constrained     [RFC 4694]
>      cic                Constrained     [RFC 4694]
>      cic-context        Constrained     [RFC 4694]
>      tgrp               Constrained     [RFC 4904]
>      trunk-context      Constrained     [RFC 4904]
>
> Thanks,
>
> - vijay
> -- 
> Vijay K. Gurbani, Bell Laboratories, Alcatel-Lucent
> 2701 Lucent Lane, Rm. 9F-546, Lisle, Illinois 60532 (USA)
> Email: vkg at {alcatel-lucent.com,bell-labs.com,acm.org}
> WWW:   http://www.alcatel-lucent.com/bell-labs
> _______________________________________________
> Iptel mailing list
> Iptel at ietf.org
> https://www.ietf.org/mailman/listinfo/iptel

_______________________________________________
Iptel mailing list
Iptel at ietf.org
https://www.ietf.org/mailman/listinfo/iptel