The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)
RFC 3969

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

(Allison Mankin) Yes

(Jon Peterson) Yes

(Harald Alvestrand) No Objection

(Steven Bellovin) No Objection

(Margaret Cullen) No Objection

(Bill Fenner) No Objection

(Ted Hardie) No Objection

Comment (2004-06-22)
No email
send info
In the parameter registry document, I think this text:

   Parameters that can appear in different header fields MAY have the
   same name. However, parameters that can appear in the same header
   field MUST have different names.

needs to be clarified.  I read it as saying that the registry may include the same
name multiple times, provided that each instance is attached to a different
header field.  If a parameter with a specific name is already associated with a
specific header, a new parameter may not be registered under that name.  
If that is correct, using language that describes the registry actions is probably
a good idea for this document; if it is not correct, I am not sure what to suggest.

While I don't wish to block the document on this, I do wonder why the uri parameter
registry did not include columns for "applies to SIP URIs" and "applies to SIPS URIs"
instead of advice to consult the specification.  I would certainly not suggest allowing
the same parameter to appear twice with different semantics, one for SIP and one for
SIPS, but the choice to elide the applicability from the registry seems odd.

(Scott Hollenbeck) No Objection

(Russ Housley) No Objection

(David Kessens) No Objection

(Thomas Narten) No Objection

(Alex Zinin) No Objection

Comment (2004-06-24)
No email
send info
> 3.  Use of the Registry
>   Registered SIP header field parameters and parameter values are to be
>   considered "reserved words". In order to preserve interoperability,
>   registered parameters and parameter values MUST be used in a manner
>   consistent with that described in their defining RFC.

The MUST above reads a bit like that for smb's evil bit.
I.e. is this a requirement for implementations of all registered params?
What is it doing here?