The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry
RFC 5341
Note: This ballot was opened for revision 06 and is now closed.
(Jon Peterson) Yes
(Jari Arkko) No Objection
(Ron Bonica) No Objection
(Ross Callon) No Objection
(Lisa Dusseault) No Objection
(Lars Eggert) (was Discuss) No Objection
Comment (2008-05-08)
No email
send info
send info
Section 3., paragraph 1: > The tel URI parameters and values for these parameters MUST be > documented in a RFC or other permanent and readily available public > specification in order to be registered by IANA. Section 4.2 defines the polocy as "Specification Required, Designated Expert" from RFC2434 - could you use that same term here? Section 4.2., paragraph 1: > As per the terminology in [6] and actions accorded to such a role, > the registration policy for tel URI parameters shall be > "Specification Required, Designated Expert" (the former implicitly > implies the latter.) Why does "Specification Required" imply "Designated Expert"? That's not the case IMO.
(Pasi Eronen) No Objection
Comment (2008-05-05 for -)
No email
send info
send info
The distinction between URI parameters that accept a set of predefined values vs. parameters that can accept any value would benefit from some clarification. Originally, I thought "predefined values" meant an enumeration (like "isub-encoding"), but later in the document, things like domain names, URIs, or strings of digits are also counted as "set of predefined values". Also, apparently there are currently no parameters in the "can accept any value" category -- so perhaps instead of talking about "predefined values", we could just classify parameters as "has a value" vs. "does not have a value"? The document probably should have "Updates: RFC 3966" on cover page since it changes the procedures defined in RFC 3966 (which says that "New mandatory parameters must be described in a standards-track RFC, but an informational RFC is sufficient for optional parameters.") Should the parameters used in obsolete RFC 2806 be marked as "reserved" in this registry? ('tsp' and 'postd')
(Russ Housley) No Objection
(Chris Newman) No Objection
Comment (2008-05-05 for -)
No email
send info
send info
Who is proposed as the designated expert for this registry? I strongly concur with all of Pasi's comments and recommend the authors consider them seriously. As a suggestion for clarity: instead of a yes/no for "predefined value", have a three-state "value-type" column that says one of: no-value, constrained, unconstrained. BTW, it appears there are no "unconstrained" parameters defined -- if that's likely to continue in the future, perhaps it's simpler to just omit the column altogether.