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