Sign in
Version 5.3.0, 2014-04-12
Report a bug

The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP)
RFC 3968

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

Summary: Needs a YES. Needs 10 more YES or NO OBJECTION positions to pass.

[Alex Zinin]

Comment (2004-06-24)

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

[Ted Hardie]

Comment (2004-06-22)

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.