summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc5341.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc5341.txt')
-rw-r--r--doc/rfc/rfc5341.txt395
1 files changed, 395 insertions, 0 deletions
diff --git a/doc/rfc/rfc5341.txt b/doc/rfc/rfc5341.txt
new file mode 100644
index 0000000..d36b0fb
--- /dev/null
+++ b/doc/rfc/rfc5341.txt
@@ -0,0 +1,395 @@
+
+
+
+
+
+
+Network Working Group C. Jennings
+Request for Comments: 5341 Cisco Systems
+Updates: 3966 V. Gurbani
+Category: Standards Track Bell Laboratories, Alcatel-Lucent
+ September 2008
+
+
+ The Internet Assigned Number Authority (IANA)
+ tel Uniform Resource Identifier (URI) Parameter Registry
+
+Status of This Memo
+
+ This document specifies an Internet standards track protocol for the
+ Internet community, and requests discussion and suggestions for
+ improvements. Please refer to the current edition of the "Internet
+ Official Protocol Standards" (STD 1) for the standardization state
+ and status of this protocol. Distribution of this memo is unlimited.
+
+Abstract
+
+ This document creates an Internet Assigned Number Authority (IANA)
+ registry for tel Uniform Resource Identifier (URI) parameters and
+ their values. It populates the registry with the parameters defined
+ in the tel URI specification, along with the parameters in tel URI
+ extensions defined for number portability and trunk groups.
+
+Table of Contents
+
+ 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 2
+ 3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . . 2
+ 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 3
+ 4.1. tel URI Parameters Registry . . . . . . . . . . . . . . . . 3
+ 4.2. Registration Policy for tel URI Parameters . . . . . . . . 4
+ 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5
+ 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5
+ 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5
+ 7.2. Informative References . . . . . . . . . . . . . . . . . . 5
+
+
+
+
+
+
+
+
+
+
+
+
+Jennings & Gurbani Standards Track [Page 1]
+
+RFC 5341 IANA Registry for TEL URI Parameters September 2008
+
+
+1. Introduction
+
+ The tel URI (RFC 3966 [1]), defines a URI that can be used to
+ represent resources identified by telephone numbers. The tel URI,
+ like many other URIs, provides extensibility through the definition
+ of new URI parameters and new values for existing parameters.
+ However, RFC 3966 did not specify an IANA registry where such
+ parameters and values can be listed and standardized. This
+ specification creates such a registry.
+
+2. Terminology
+
+ The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
+ "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
+ document are to be interpreted as described in [2].
+
+3. Use of the Registry
+
+ The tel URI parameters and values for these parameters MUST be
+ documented in a RFC or other permanent and readily available public
+ specification 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.
+
+ Documents defining tel URI parameters or parameter values MUST
+ register them with IANA, as described in Section 4. The IANA
+ registration policy for such parameters is "Specification Required,
+ Designated Expert," and is further discussed in Section 4.2.
+
+ Some tel URI parameters only accept a set of predefined parameter
+ values while others can take any value. There are also parameters
+ that do not have any value; they are used as flags.
+
+ Those URI parameters that take on predefined values typically take on
+ a large number of values. Registering each of those values, or
+ creating a sub-registry for each such parameter is not appropriate.
+ Instead, we have chosen to register URI parameter values by
+ reference. That is, the entry in the URI parameter registry for a
+ given URI parameter contains references to the RFCs defining new
+ values of that parameter.
+
+ Accordingly, the tel URI parameter registry contains a column that
+ indicates whether or not each parameter accepts a value. The column
+ may contain "No value" or "Constrained". A "Constrained" in the
+ column implies that certain predefined values exist for this
+
+
+
+Jennings & Gurbani Standards Track [Page 2]
+
+RFC 5341 IANA Registry for TEL URI Parameters September 2008
+
+
+ parameter and the accompanying RFC or other permanent and readily
+ available public specification should be consulted to find out the
+ accepted set of values. A "No Value" in the column implies that the
+ parameter is used either as a flag, or does not have a set of
+ predefined values. The accompanying RFC or other permanent and
+ readily available public specification should provide more
+ information on the semantics of the parameter.
+
+4. IANA Considerations
+
+ The specification creates a new IANA registry named "tel URI
+ Parameters".
+
+4.1. tel URI Parameters Registry
+
+ New tel URI parameters and new values for existing tel URI parameters
+ MUST be registered with IANA.
+
+ When registering a new tel URI parameter, the following information
+ MUST be provided:
+
+ o Name of the parameter.
+
+ o Whether the parameter only accepts a set of predefined values.
+
+ o Reference to the RFC or other permanent and readily available
+ public specification defining the parameter and new values.
+
+ When registering a new value for an existing tel URI parameter, the
+ following information MUST be provided:
+
+ o Name of the parameter.
+
+ o Reference to the RFC or other permanent and readily available
+ public specification providing the new value.
+
+ Table 1 contains the initial values for this registry.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jennings & Gurbani Standards Track [Page 3]
+
+RFC 5341 IANA Registry for TEL URI Parameters September 2008
+
+
+ Parameter Name Predefined Values Reference
+ -------------- ----------------- ---------
+ isub Constrained [RFC3966]
+ isub-encoding Constrained [RFC4715]
+ ext Constrained [RFC3966]
+ phone-context Constrained [RFC3966]
+ enumdi No value [RFC4759]
+ npdi No value [RFC4694]
+ rn Constrained [RFC4694]
+ rn-context Constrained [RFC4694]
+ cic Constrained [RFC4694]
+ cic-context Constrained [RFC4694]
+ tgrp Constrained [RFC4904]
+ trunk-context Constrained [RFC4904]
+
+ Table 1: IANA tel URI parameter registry
+
+4.2. Registration Policy for tel URI Parameters
+
+ As per the terminology in [3] and actions accorded to such a role,
+ the registration policy for tel URI parameters shall be
+ "Specification Required, Designated Expert" (the former implicitly
+ implies the latter).
+
+ The Designated Expert, when deliberating on whether to include a new
+ parameter in the tel URI registry, may use the criteria provided
+ below to reach a decision (this is not an exhaustive list but
+ representative of the issues to consider when rendering an equitable
+ decision):
+
+ o If the tel URI -- with the parameter under consideration -- will
+ be converted to a URI used by other signaling protocols such as
+ the Session Initiation Protocol (SIP [5]) or H.323 [7], then the
+ expert must consider whether this parameter merely encapsulates
+ signaling information that is not meaningful to the processing of
+ requests in the domain of the converted URI. For example, certain
+ Integrated Services Digital Network (ISDN) User Part (ISUP, [8])
+ parameters have no equivalent corollary in SIP; thus, their
+ presence or absence in a SIP URI will not hinder the normal rules
+ for processing that URI. Other parameters may affect the normal
+ processing rules associated with the URI; in such cases, the
+ expert must carefully consider the ramifications, if any, of the
+ presence of such parameters.
+
+ o Certain parameters of a tel URI can be optional. These parameters
+ act as metadata about the identifier in the tel URI. Optional
+ parameters should provide additional information to a service for
+ which they apply instead of acting as enablers of that service in
+
+
+
+Jennings & Gurbani Standards Track [Page 4]
+
+RFC 5341 IANA Registry for TEL URI Parameters September 2008
+
+
+ the first place. The service must continue to be invoked and
+ operate normally even in the absence of these parameters.
+
+5. Security Considerations
+
+ The registry in this document does not in itself have security
+ considerations. However, as mentioned in [4], 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 in
+ this specification MUST provide detailed security considerations for
+ them.
+
+6. Acknowledgments
+
+ The structure of this document comes from [6], which is the
+ equivalent work done in the SIP domain to establish a registry. Ted
+ Hardie, Alfred Hoenes, Jon Peterson, and Jonathan Rosenberg provided
+ substantive comments that have improved this document.
+
+ Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, and Glen
+ Zorn provided feedback during IESG review and Gen-ART review.
+
+7. References
+
+7.1. Normative References
+
+ [1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,
+ December 2004.
+
+ [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
+ Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
+
+7.2. Informative References
+
+ [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.
+
+ [5] 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.
+
+
+
+
+
+
+Jennings & Gurbani Standards Track [Page 5]
+
+RFC 5341 IANA Registry for TEL URI Parameters September 2008
+
+
+ [6] Camarillo, G., "The Internet Assigned Number Authority (IANA)
+ Uniform Resource Identifier (URI) Parameter Registry for the
+ Session Initiation Protocol (SIP)", BCP 99, RFC 3969,
+ December 2004.
+
+ [7] ITU-T H.323, "H.323: Packet-based multimedia communications
+ systems", June 2006.
+
+ [8] ITU-T Q.764, "Signaling System No. 7: ISDN User Part Signaling
+ Procedures", December 1999.
+
+Authors' Addresses
+
+ Cullen Jennings
+ Cisco Systems
+ 170 West Tasman Drive
+ Mailstop SJC-21/2
+ San Jose, CA 95134
+ USA
+
+ Phone: +1 408 902-3341
+ EMail: fluffy@cisco.com
+
+
+ Vijay K. Gurbani
+ Bell Laboratories, Alcatel-Lucent
+ 2701 Lucent Lane
+ Room 9F-546
+ Lisle, IL 60532
+ USA
+
+ Phone: +1 630 224-0216
+ EMail: vkg@alcatel-lucent.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Jennings & Gurbani Standards Track [Page 6]
+
+RFC 5341 IANA Registry for TEL URI Parameters September 2008
+
+
+Full Copyright Statement
+
+ Copyright (C) The IETF Trust (2008).
+
+ 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, THE IETF TRUST 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 procedures with respect to rights in RFC 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.
+
+
+
+
+
+
+
+
+
+
+
+
+Jennings & Gurbani Standards Track [Page 7]
+