Skip to content

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

  • G. Camarillo
Best Current Practice
Network Working Group                                       G. Camarillo
Request for Comments: 3968                                      Ericsson
Updates:                                               December 2004
BCP: 98
Category: Best Current Practice


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

Status of This Memo

   This document specifies an Internet Best Current Practices for the
   Internet Community, and requests discussion and suggestions for
   improvements.  Distribution of this memo is unlimited.

Copyright Notice

   Copyright (C) The Internet Society (2004).

Abstract

   This document creates an Internet Assigned Number Authority (IANA)
   registry for the Session Initiation Protocol (SIP) header field
   parameters and parameter values.  It also lists the already existing
   parameters and parameter values to be used as the initial entries for
   this registry.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  2
   3.  Use of the Registry  . . . . . . . . . . . . . . . . . . . . .  2
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  3
       4.1.  Header Field Parameters Sub-Registry . . . . . . . . . .  3
       4.2.  Registration Policy for SIP Header Field Parameters. . .  6
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . .  7
   6.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  7
   7.  Normative References . . . . . . . . . . . . . . . . . . . . .  7
       Author's Address . . . . . . . . . . . . . . . . . . . . . . .  7
       Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8









Camarillo                Best Current Practice                  [Page 1]

                 SIP Parameter Registry            December 2004


1.  Introduction

    [3] allows new header field parameters and new parameter
   values to be defined.  However,  omitted an IANA registry for
   them.  This document creates such a registry.

    [4] documents the process to extend SIP.  This document
   updates  by specifying how to define and register new SIP
   header field parameters and parameter values.

2.  Terminology

   In this document, the key words "MUST", "MUST NOT", "REQUIRED",
   "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT
   RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as
   described in BCP 14,  [1] and indicate requirement levels for
   compliant implementations.

3.  Use of the Registry

   SIP header field parameters and parameter values MUST be documented
   in an RFC in order to be registered by IANA.  This documentation MUST
   fully explain the syntax, intended usage, and semantics of the
   parameter or parameter value.  The intent of this requirement is to
   assure interoperability between independent implementations, and to
   prevent accidental namespace collisions between implementations of
   dissimilar features.

      Note that this registry, unlike other protocol registries, only
      deals with parameters and parameter values defined in RFCs (i.e.,
      it lacks a vendor-extension tree).   [4] documents
      concerns with regards to new SIP extensions which may damage
      security, greatly increase the complexity of the protocol, or
      both.  New parameters and parameter values need to be documented
      in RFCs as a result of these concerns.

   RFCs defining SIP header field parameters or parameter values MUST
   register them with IANA as described below.

   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.
   Implementations MUST NOT utilize "private" or "locally defined" SIP
   header field parameters or parameter values that conflict with
   registered parameters.





Camarillo                Best Current Practice                  [Page 2]

                 SIP Parameter Registry            December 2004


      Note that although unregistered SIP header field parameters and
      parameter values may be used in implementations, developers are
      cautioned that usage of such parameters is risky.  New SIP header
      field parameters and parameter values may be registered at any
      time, and there is no assurance that these new registered
      parameters or parameter values will not conflict with unregistered
      parameters currently in use.

   Some SIP header field parameters only accept a set of predefined
   parameter values.  For example, a parameter indicating the transport
   protocol in use may only accept the predefined tokens TCP, UDP, and
   SCTP as valid values.  Registering all parameter values for all SIP
   header field parameters of this type would require a large number of
   subregistries.  Instead, we have chosen to register parameter values
   by reference.  That is, the entry in the parameter registry for a
   given header field parameter contains references to the RFCs defining
   new values of the parameter.  References to RFCs defining parameter
   values appear in double brackets in the registry.

   So, the header field parameter registry contains a column that
   indicates whether or not each parameter only accepts a set of
   predefined values.  Implementers of parameters with a "yes" in that
   column need to find all the valid parameter values in the RFCs
   provided as references.

4.  IANA Considerations

    [3] creates an IANA registry for method names,
   header field names, warning codes, status codes, and option tags.
   This specification creates a new sub-registry for header field
   parameters under the SIP Parameters registry.

4.1.  Header Field Parameters Sub-Registry

   The majority of the SIP header fields can be extended by defining new
   parameters.  New SIP header field parameters are registered by the
   IANA.  When registering a new parameter for a header field or a new
   value for a parameter, the following information MUST be provided.

   o  Header field in which the parameter can appear.

   o  Name of the header field parameter being registered.

   o  Whether the parameter only accepts a set of predefined values.







Camarillo                Best Current Practice                  [Page 3]

                 SIP Parameter Registry            December 2004


   o  A reference to the RFC where the parameter is defined and to any
      RFC that defines new values for the parameter.  References to RFCs
      defining parameter values appear in double brackets in the
      registry.

   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.

   The following are the initial values for this sub-registry.

   Header Field                  Parameter Name   Predefined  Reference
                                                    Values
   _____________________________________________________________________
   Accept                        q                    No     []
   Accept-Encoding               q                    No     []
   Accept-Language               q                    No     []
   Authorization                 algorithm           Yes     []
                                                            [[]]
   Authorization                 auts                 No     []
   Authorization                 cnonce               No     []
   Authorization                 nc                   No     []
   Authorization                 nonce                No     []
   Authorization                 opaque               No     []
   Authorization                 qop                 Yes     []
   Authorization                 realm                No     []
   Authorization                 response             No     []
   Authorization                 uri                  No     []
   Authorization                 username             No     []
   Authentication-Info           cnonce               No     []
   Authentication-Info           nc                   No     []
   Authentication-Info           nextnonce            No     []
   Authentication-Info           qop                 Yes     []
   Authentication-Info           rspauth              No     []
   Call-Info                     purpose             Yes     []
   Contact                       expires              No     []
   Contact                       q                    No     []
   Content-Disposition           handling            Yes     []
   Event                         id                   No     []
   From                          tag                  No     []
   P-Access-Network-Info         cgi-3gpp             No     []
   P-Access-Network-Info         utran-cell-id-3gpp   No     []
   P-Charging-Function-Addresses ccf                  No     []
   P-Charging-Function-Addresses ecf                  No     []
   P-Charging-Vector             icid-value           No     []
   P-Charging-Vector             icid-generated-at    No     []
   P-Charging-Vector             orig-ioi             No     []
   P-Charging-Vector             term-ioi             No     []



Camarillo                Best Current Practice                  [Page 4]

                 SIP Parameter Registry            December 2004


   P-DCS-Billing-Info            called               No     []
   P-DCS-Billing-Info            calling              No     []
   P-DCS-Billing-Info            charge               No     []
   P-DCS-Billing-Info            locroute             No     []
   P-DCS-Billing-Info            rksgroup             No     []
   P-DCS-Billing-Info            routing              No     []
   P-DCS-LAES                    content              No     []
   P-DCS-LAES                    key                  No     []
   P-DCS-Redirect                count                No     []
   P-DCS-Redirect                redirector-uri       No     []
   Proxy-Authenticate            algorithm           Yes     []
                                                            [[]]
   Proxy-Authenticate            domain               No     []
   Proxy-Authenticate            nonce                No     []
   Proxy-Authenticate            opaque               No     []
   Proxy-Authenticate            qop                 Yes     []
   Proxy-Authenticate            realm                No     []
   Proxy-Authenticate            stale               Yes     []
   Proxy-Authorization           algorithm           Yes     []
                                                            [[]]
   Proxy-Authorization           auts                 No     []
   Proxy-Authorization           cnonce               No     []
   Proxy-Authorization           nc                   No     []
   Proxy-Authorization           nonce                No     []
   Proxy-Authorization           opaque               No     []
   Proxy-Authorization           qop                 Yes     []
   Proxy-Authorization           realm                No     []
   Proxy-Authorization           response             No     []
   Proxy-Authorization           uri                  No     []
   Proxy-Authorization           username             No     []
   Reason                        cause               Yes     []
   Reason                        text                 No     []
   Retry-After                   duration             No     []
   Security-Client               alg                 Yes     []
   Security-Client               ealg                Yes     []
   Security-Client               d-alg               Yes     []
   Security-Client               d-qop               Yes     []
   Security-Client               d-ver                No     []
   Security-Client               mod                 Yes     []
   Security-Client               port1                No     []
   Security-Client               port2                No     []
   Security-Client               prot                Yes     []
   Security-Client               q                    No     []
   Security-Client               spi                  No     []
   Security-Server               alg                 Yes     []
   Security-Server               ealg                Yes     []
   Security-Server               d-alg               Yes     []
   Security-Server               d-qop               Yes     []



Camarillo                Best Current Practice                  [Page 5]

                 SIP Parameter Registry            December 2004


   Security-Server               d-ver                No     []
   Security-Server               mod                 Yes     []
   Security-Server               port1                No     []
   Security-Server               port2                No     []
   Security-Server               prot                Yes     []
   Security-Server               q                    No     []
   Security-Server               spi                  No     []
   Security-Verify               alg                 Yes     []
   Security-Verify               ealg                Yes     []
   Security-Verify               d-alg               Yes     []
   Security-Verify               d-qop               Yes     []
   Security-Verify               d-ver                No     []
   Security-Verify               mod                 Yes     []
   Security-Verify               port1                No     []
   Security-Verify               port2                No     []
   Security-Verify               prot                Yes     []
   Security-Verify               q                    No     []
   Security-Verify               spi                  No     []
   Subscription-State            expires              No     []
   Subscription-State            reason              Yes     []
   Subscription-State            retry-after          No     []
   To                            tag                  No     []
   Via                           branch               No     []
   Via                           comp                Yes     []
   Via                           maddr                No     []
   Via                           received             No     []
   Via                           rport                No     []
   Via                           ttl                  No     []
   WWW-Authenticate              algorithm           Yes     []
                                                            [[]]
   WWW-Authenticate              domain              Yes     []
   WWW-Authenticate              nonce                No     []
   WWW-Authenticate              opaque               No     []
   WWW-Authenticate              qop                 Yes     []
   WWW-Authenticate              realm                No     []
   WWW-Authenticate              stale               Yes     []

4.2.  Registration Policy for SIP Header Field Parameters

   As per the terminology in  [2], the registration policy for
   SIP header field parameters and parameter values shall be "IETF
   Consensus."

   For the purposes of this registry, the parameter or the parameter
   value for which IANA registration is requested MUST be defined by an
   RFC.  There is no requirement that this RFC be standards-track.





Camarillo                Best Current Practice                  [Page 6]

                 SIP Parameter Registry            December 2004


5.  Security Considerations

   The registry in this document does not in itself have security
   considerations.  However, as mentioned in , an important
   reason for the IETF to manage the extensions of SIP is to ensure that
   all extensions and parameters are able to provide secure usage.  The
   supporting RFC publications for parameter registrations described
   this specification MUST provide detailed security considerations for
   them.

6.  Acknowledgements

   Jonathan Rosenberg, Henning Schulzrinne, Rohan Mahy, Dean Willis, Aki
   Niemi, Bill Marshall, Miguel A. Garcia-Martin, Jean Francois Mule,
   and Allison Mankin provided useful comments on this document.

7.  Normative References

   [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
       Levels", BCP 14, , March 1997.

   [2] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
       Considerations Section in RFCs", BCP 26, , October 1998.

   [3] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
       Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
       Session Initiation Protocol", , June 2002.

   [4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B.
       Rosen, "Change Process for the Session Initiation Protocol
       (SIP)", BCP 67, , December 2002.

Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com










Camarillo                Best Current Practice                  [Page 7]

                 SIP Parameter Registry            December 2004


Full Copyright Statement

   Copyright (C) The Internet Society (2004).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the IETF's procedures with respect to rights in IETF Documents can
   be found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

Acknowledgement

   Funding for the RFC Editor function is currently provided by the
   Internet Society.







Camarillo                Best Current Practice                  [Page 8]

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

Best Current Practice