From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc5341.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc5341.txt (limited to 'doc/rfc/rfc5341.txt') 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] + -- cgit v1.2.3