doc: Add RFC documents

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]
+