The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP)
RFC 3969
Document | Type |
RFC - Best Current Practice
(December 2004; No errata)
Updated by RFC 5727
Updates RFC 3427
Also known as BCP 99
|
|
---|---|---|---|
Author | Gonzalo Camarillo | ||
Last updated | 2015-10-14 | ||
Stream | Internet Engineering Task Force (IETF) | ||
Formats | plain text html pdf htmlized (tools) htmlized bibtex | ||
Stream | WG state | (None) | |
Document shepherd | No shepherd assigned | ||
IESG | IESG state | RFC 3969 (Best Current Practice) | |
Action Holders |
(None)
|
||
Consensus Boilerplate | Unknown | ||
Telechat date | |||
Responsible AD | Allison Mankin | ||
Send notices to | rohan@cisco.com, jon.peterson@neustar.biz |
Network Working Group G. Camarillo Request for Comments: 3969 Ericsson Updates: 3427 December 2004 BCP: 99 Category: Best Current Practice The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) 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) and SIPS Uniform Resource Identifier (URI) parameters, and their values. It also lists the already existing parameters to be used as initial values for that registry. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology. . . . . . . . . . . . . . . . . . . . . . . . . . 2 3. Use of the Registry. . . . . . . . . . . . . . . . . . . . . . 2 4. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 3 4.1. SIP and SIPS URI Parameters Sub-Registry . . . . . . . . 3 4.2. Registration Policy for SIP and SIPS URI Parameters. . . 4 5. Security Considerations. . . . . . . . . . . . . . . . . . . . 4 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 7. Normative References . . . . . . . . . . . . . . . . . . . . . 5 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 5 Full Copyright Statement . . . . . . . . . . . . . . . . . . . 6 Camarillo Best Current Practice [Page 1] RFC 3969 IANA URI Parameter Registry for SIP December 2004 1. Introduction RFC 3261 [1] allows new SIP URI and SIPS URI 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 [2] documents the process to extend SIP. This document updates RFC 3427 by specifying how to define and register new SIP and SIP URI parameters and their values. 2. Terminology In this document, the key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" are to be interpreted as described in BCP 14, RFC 2119 [3] and indicate requirement levels for compliant SIP implementations. 3. Use of the Registry SIP and SIPS URI parameters and values for these parameters MUST be documented in a standards-track RFC in order to be registered by IANA. This documentation MUST fully explain the syntax, intended usage, and semantics of the parameter. 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 [2] 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 URI, SIPS URI parameters, or parameter values MUST register them with IANA as described below. Registered SIP and SIPS URI parameters and their values are to be considered "reserved words". In order to preserve interoperability, registered parameters MUST be used in a manner consistent with that described in their defining RFC. Implementations MUST NOT utilize "private" or "locally defined" URI parameters that conflict with registered parameters. Camarillo Best Current Practice [Page 2] RFC 3969 IANA URI Parameter Registry for SIP December 2004 Note that although unregistered SIP and SIPS URI parameters may be used in implementations, developers are cautioned that usage of such parameters is risky. New SIP and SIPS URI parameters and new values for them may be registered at any time, and there is no assurance that these new registered URI parameters will not conflict with unregistered parameters currently in use. Some SIP and SIPS URI 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 SIPShow full document text