The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)
draft-ietf-sip-parameter-registry-02

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

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.