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

[Jonathan Rosenberg <[e-mail]>]

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:

> This document creates an Internet Assigned Number Authority (IANA)
>    registry for the tel Uniform Resource Identifier (URI) parameters,

s/for the tel/for tel

and remove the comma at the end of the second line

> It also lists the already existing parameters to
>    be used as initial values for that registry.

I think this is better said thusly:

It also populates the registry with the parameters defined in the tel 
URI specification, along with the parameters in extensions defined for 
number portability and trunk groups.

> Jennings & Gurbani        Expires June 9, 2006                  [Page 1]
> 
> Internet-Draft    IANA Registry for TEL URI Parameters          Dec 2005

s/TEL/tel

> 1.  Introduction
> 
>    RFC 3966 [1] allows new tel URI parameters, and new parameter values
>    to be defined.  

Suggest:

The tel URI, defined in RFC 3966 [1], defines a URI that can be used to 
represent resources identified by telephone numbers. The tel URI, like 
many other URIs, provides extensibility through the definition of new 
URI parameters and new values for existing parameters.

> RFCs defining tel URI parameters, or parameter values MUST register
>    them with IANA as described below.

remove the comma

>  Registered tel URI parameters and their values are to be considered
>    "reserved words".  In order to preserve interoperability, registered
>    parameters MUST be used in a manner consistent with that described in
>    their defining RFC.  Implementations MUST NOT utilize "private" or
>    "locally defined" URI parameters that conflict with registered
>    parameters.

this paragraph basically says to read the specs and be good. THats 
motherhood and apple-pie kind of stuff. I think you should remove the 
paragraph, it seems out of place anyway.

> Some tel URI parameters only accept a set of predefined parameter
>    values while others can take any value.  There are also parameters
>    that can not have any value.  

suggest for the last sentence:

There are also parameters which take no values; they are used as flags.

> Registering all parameter values for
>    all tel URI parameters of this type would require a large number of
>    sub-registries. 

this sentence doesn't work where its currently placed. The words "this 
type" would normally refer to the previous sentence. But they don't; the 
previous sentence talks about parameters with no values. I'd suggest:

Those URI parameters which take on predefined values typically take on a 
large number of values. Registering each of those values, or creating a 
sub-registry for each such parameter, is not appropriate.

> 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.

>  New tel URI parameters and new parameter values are registered by the
>    IANA.

...and new parameter values for existing URI parameters are registered...

> 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.

>  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.

If you read RFC2434, it says this about "specification required":

  Specification Required - Values and their meaning must be
            documented in an RFC or other permanent and readily available
            reference, in sufficient detail so that interoperability
            between independent implementations is possible.

            Examples: SCSP [SCSP]


"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
            RFCs approved by the IESG.

            Examples: MIME top level types [MIME-REG]



Thanks,
Jonahtan R.

Vijay K. Gurbani wrote:

> Folks:
> 
> I have submitted draft-ietf-iptel-tel-reg-00.
> 
> Until it becomes available in the archives, you can get it from
> 
> http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-tel-reg-00.txt
> http://www.iit.edu/~gurbvij/I-D/draft-ietf-iptel-tel-reg-00.html
> 
> Thanks.
> 
> - vijay

-- 
Jonathan D. Rosenberg, Ph.D.                   600 Lanidex Plaza
Cisco Fellow                                   Parsippany, NJ 07054-2711
Cisco Systems
[e-mail]                              FAX:   [phone]
http://www.jdrosen.net                         PHONE: [phone]
http://www.cisco.com

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