[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: (draft-camarillo-sip-parameter-registry) 00 01 02 RFC 3968

SIP Working Group                                           G. Camarillo
Internet-Draft                                                  Ericsson
Expires: December 15, 2004                                 June 16, 2004


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

Status of this Memo

   By submitting this Internet-Draft, I certify that any applicable
   patent or other IPR claims of which I am aware have been disclosed,
   and any of which I become aware will be disclosed, in accordance with
   RFC 3668.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that other
   groups may also distribute working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at http://
   www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on December 15, 2004.

Copyright Notice

   Copyright (C) The Internet Society (2004). All Rights Reserved.

Abstract

   This document creates an IANA registry for 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.









Camarillo              Expires December 15, 2004                [Page 1]

Internet-Draft           SIP Parameter Registry                June 2004


Table of Contents

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






































Camarillo              Expires December 15, 2004                [Page 2]

Internet-Draft           SIP Parameter Registry                June 2004


1.  Introduction

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

   RFC 3427 [4] documents the process to extend SIP. This document
   updates RFC 3427 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, RFC 2119 [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). RFC 3427 [4] documents concerns
      with regards to new SIP extensions which may be damaging towards
      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              Expires December 15, 2004                [Page 3]

Internet-Draft           SIP Parameter Registry                June 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 as valid values the predefined tokens
   TCP, UDP, and SCTP. 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 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

   Section 27 of RFC 3261 [3] creates an IANA registry for method names,
   header field names, warning codes, status codes, and option tags.
   This specification instructs the IANA to create a new sub-registry
   for header field parameters under

   http://www.iana.org/assignments/sip-parameters:

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.
   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 brackets in the registry.




Camarillo              Expires December 15, 2004                [Page 4]

Internet-Draft           SIP Parameter Registry                June 2004


   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      RFC 3261
   Accept-Encoding               q                    No      RFC 3261
   Accept-Language               q                    No      RFC 3261
   Authorization                 algorithm           Yes      RFC 3261
                                                             [RFC 3310]
   Authorization                 auts                 No      RFC 3310
   Authorization                 cnonce               No      RFC 3261
   Authorization                 nc                   No      RFC 3261
   Authorization                 nonce                No      RFC 3261
   Authorization                 opaque               No      RFC 3261
   Authorization                 qop                 Yes      RFC 3261
   Authorization                 realm                No      RFC 3261
   Authorization                 response             No      RFC 3261
   Authorization                 uri                  No      RFC 3261
   Authorization                 username             No      RFC 3261
   Authentication-Info           cnonce               No      RFC 3261
   Authentication-Info           nc                   No      RFC 3261
   Authentication-Info           nextnonce            No      RFC 3261
   Authentication-Info           qop                 Yes      RFC 3261
   Authentication-Info           rspauth              No      RFC 3261
   Call-Info                     purpose             Yes      RFC 3261
   Contact                       expires              No      RFC 3261
   Contact                       q                    No      RFC 3261
   Content-Disposition           handling            Yes      RFC 3261
   Event                         id                   No      RFC 3265
   From                          tag                  No      RFC 3261
   P-Access-Network-Info         cgi-3gpp             No      RFC 3455
   P-Access-Network-Info         utran-cell-id-3gpp   No      RFC 3455
   P-Charging-Function-Addresses ccf                  No      RFC 3455
   P-Charging-Function-Addresses ecf                  No      RFC 3455
   P-Charging-Vector             icid-value           No      RFC 3455
   P-Charging-Vector             icid-generated-at    No      RFC 3455
   P-Charging-Vector             orig-ioi             No      RFC 3455
   P-Charging-Vector             term-ioi             No      RFC 3455
   P-DCS-Billing-Info            called               No      RFC 3603
   P-DCS-Billing-Info            calling              No      RFC 3603
   P-DCS-Billing-Info            charge               No      RFC 3603
   P-DCS-Billing-Info            locroute             No      RFC 3603



Camarillo              Expires December 15, 2004                [Page 5]

Internet-Draft           SIP Parameter Registry                June 2004


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



Camarillo              Expires December 15, 2004                [Page 6]

Internet-Draft           SIP Parameter Registry                June 2004


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


4.2  Registration Policy for SIP Header Field Parameters

   As per the terminology in RFC 2434 [2], the registration policy for
   SIP header field parameters and parameter values shall be
   "Specification Required".

   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.

5.  Security Considerations

   There are no security considerations associated to this document.




Camarillo              Expires December 15, 2004                [Page 7]

Internet-Draft           SIP Parameter Registry                June 2004


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.

7  Normative References

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

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

   [3]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, 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, RFC 3427, December 2002.


Author's Address

   Gonzalo Camarillo
   Ericsson
   Hirsalantie 11
   Jorvas  02420
   Finland

   EMail: Gonzalo.Camarillo@ericsson.com



















Camarillo              Expires December 15, 2004                [Page 8]

Internet-Draft           SIP Parameter Registry                June 2004


Intellectual Property Statement

   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.


Disclaimer of Validity

   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.


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.


Acknowledgment

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




Camarillo              Expires December 15, 2004                [Page 9]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/