Skip to main content

The Internet Assigned Number Authority (IANA) tel Uniform Resource Identifier (URI) Parameter Registry
RFC 5341

Yes

(Jon Peterson)

No Objection

(Dan Romascanu)
(David Ward)
(Jari Arkko)
(Lisa Dusseault)
(Magnus Westerlund)
(Ron Bonica)
(Ross Callon)
(Russ Housley)
(Tim Polk)

Recuse

(Cullen Jennings)

Note: This ballot was opened for revision 06 and is now closed.

Lars Eggert
(was Discuss) No Objection
Comment (2008-05-08) Unknown
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.
Jon Peterson Former IESG member
Yes
Yes () Unknown

                            
Chris Newman Former IESG member
No Objection
No Objection (2008-05-05) Unknown
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.
Dan Romascanu Former IESG member
No Objection
No Objection () Unknown

                            
David Ward Former IESG member
No Objection
No Objection () Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection () Unknown

                            
Lisa Dusseault Former IESG member
No Objection
No Objection () Unknown

                            
Magnus Westerlund Former IESG member
No Objection
No Objection () Unknown

                            
Pasi Eronen Former IESG member
No Objection
No Objection (2008-05-05) Unknown
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')
Ron Bonica Former IESG member
No Objection
No Objection () Unknown

                            
Ross Callon Former IESG member
No Objection
No Objection () Unknown

                            
Russ Housley Former IESG member
No Objection
No Objection () Unknown

                            
Tim Polk Former IESG member
No Objection
No Objection () Unknown

                            
Cullen Jennings Former IESG member
Recuse
Recuse () Unknown