diff options
Diffstat (limited to 'doc/rfc/rfc3968.txt')
| -rw-r--r-- | doc/rfc/rfc3968.txt | 451 |
1 files changed, 451 insertions, 0 deletions
diff --git a/doc/rfc/rfc3968.txt b/doc/rfc/rfc3968.txt new file mode 100644 index 0000000..fda3c4e --- /dev/null +++ b/doc/rfc/rfc3968.txt @@ -0,0 +1,451 @@ + + + + + + +Network Working Group G. Camarillo +Request for Comments: 3968 Ericsson +Updates: 3427 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] + +RFC 3968 SIP Parameter Registry December 2004 + + +1. Introduction + + RFC 3261 [3] allows new header field parameters and new parameter + values to be defined. However, RFC 3261 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 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] + +RFC 3968 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 + + 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 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] + +RFC 3968 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 [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] + + + +Camarillo Best Current Practice [Page 4] + +RFC 3968 SIP Parameter Registry December 2004 + + + 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] + 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] + + + +Camarillo Best Current Practice [Page 5] + +RFC 3968 SIP Parameter Registry December 2004 + + + 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] + 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 "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] + +RFC 3968 SIP Parameter Registry December 2004 + + +5. Security Considerations + + The registry in this document does not in itself have security + considerations. However, as mentioned in RFC 3427, 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, 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 Best Current Practice [Page 7] + +RFC 3968 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] + |