[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Iptel] draft-ietf-iptel-reg-05
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