idnits 2.17.1 draft-ietf-iptel-tel-reg-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 305. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 312. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 318. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 25, 2008) is 5869 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'RFC 3966' on line 159 -- Looks like a reference, but probably isn't: 'RFC 4715' on line 157 -- Looks like a reference, but probably isn't: 'RFC 4759' on line 160 -- Looks like a reference, but probably isn't: 'RFC 4694' on line 165 -- Looks like a reference, but probably isn't: 'RFC 4904' on line 167 -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '3') (Obsoleted by RFC 5727) == Outdated reference: A later version (-09) exists of draft-narten-iana-considerations-rfc2434bis-08 Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPTEL WG C. Jennings 3 Internet-Draft Cisco Systems 4 Intended status: Best Current V. Gurbani 5 Practice Bell Laboratories, Alcatel-Lucent 6 Expires: September 26, 2008 March 25, 2008 8 The Internet Assigned Number Authority (IANA) tel Uniform Resource 9 Identifier (URI) Parameter Registry 10 draft-ietf-iptel-tel-reg-05 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on September 26, 2008. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2008). 41 Abstract 43 This document creates an Internet Assigned Number Authority (IANA) 44 registry for tel Uniform Resource Identifier (URI) parameters and 45 their values. It populates the registry with the parameters defined 46 in the tel URI specification, along with the parameters in tel URI 47 extensions defined for number portability and trunk groups. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . . 3 54 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 55 4.1. tel URI Parameters Registry . . . . . . . . . . . . . . . . 4 56 4.2. Registration Policy for tel URI Parameters . . . . . . . . 5 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 63 Intellectual Property and Copyright Statements . . . . . . . . . . 8 65 1. Introduction 67 The tel URI [1], defines a URI that can be used to represent 68 resources identified by telephone numbers. The tel URI, like many 69 other URIs, provides extensibility through the definition of new URI 70 parameters and new values for existing parameters. However, RFC3966 71 did not specify an IANA registry where such parameters and values can 72 be listed and standardized. This specification creates such a 73 registry. 75 2. Terminology 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in [2]. 81 3. Use of the Registry 83 The tel URI parameters and values for these parameters MUST be 84 documented in a RFC or other permanent and readily available public 85 specification in order to be registered by IANA. This documentation 86 MUST fully explain the syntax, intended usage, and semantics of the 87 parameter. The intent of this requirement is to assure 88 interoperability between independent implementations, and to prevent 89 accidental namespace collisions between implementations of dissimilar 90 features. 92 RFCs defining tel URI parameters or parameter values MUST register 93 them with IANA as described below. 95 Some tel URI parameters only accept a set of predefined parameter 96 values while others can take any value. There are also parameters 97 that do not have any value; they are used as flags. 99 Those URI parameters that take on predefined values typically take on 100 a large number of values. Registering each of those values, or 101 creating a sub-registry for each such parameter is not appropriate. 102 Instead, we have chosen to register URI parameter values by 103 reference. That is, the entry in the URI parameter registry for a 104 given URI parameter contains references to the RFCs defining new 105 values of that parameter. 107 Accordingly, the tel URI parameter registry contains a column that 108 indicates whether or not each parameter only accepts a set of 109 predefined values. The column can contain "Yes", or "No". A value 110 of "Yes" in the column implies that certain predefined values exist 111 for this parameter and the accompanying RFC or other permanent and 112 readily available public specification should be consulted to find 113 out the accepted set of values. A value of "No" in the column 114 implies that the parameter is used either as a flag, or does not have 115 a set of predefined values. The accompanying RFC or other permanent 116 and readily available public specification should provide more 117 information on the semantics of the parameter. 119 4. IANA Considerations 121 The specification creates a new IANA registry named "tel URI 122 Parameters". 124 4.1. tel URI Parameters Registry 126 New tel URI parameters and new values for existing tel URI parameters 127 MUST be registered by IANA. 129 When registering a new tel URI parameter the following information 130 MUST be provided: 132 o Name of the parameter. 134 o Whether the parameter only accepts a set of predefined values. 136 o Reference to the RFC or other permanent and readily available 137 public specification defining the parameter and new values. 139 When registering a new value for an existing tel URI parameter the 140 following information MUST be provided: 142 o Name of the parameter. 144 o Reference to the RFC or other permanent and readily available 145 public specification providing the new value. 147 Note to IANA editor: When a new value for an existing tel URI 148 parameter is standardized, the Reference column of Table 1 (below) 149 corresponding to the parameter name must be updated to include the 150 new RFC number. 152 Table 1 contains the initial values for this registry. 154 Parameter Name Predefined Values Reference 155 -------------- ----------------- --------- 156 isub Yes [RFC 3966] 157 isub-encoding Yes [RFC 4715] 158 ext Yes [RFC 3966] 159 phone-context Yes [RFC 3966] 160 enumdi No [RFC 4759] 161 npdi No [RFC 4694] 162 rn Yes [RFC 4694] 163 rn-context Yes [RFC 4694] 164 cic Yes [RFC 4694] 165 cic-context Yes [RFC 4694] 166 tgrp Yes [RFC 4904] 167 trunk-context Yes [RFC 4904] 169 Table 1: IANA tel URI parameter registry 171 4.2. Registration Policy for tel URI Parameters 173 As per the terminology in [6] and actions accorded to such a role, 174 the registration policy for tel URI parameters shall be 175 "Specification Required, Designated Expert" (the former implicitly 176 implies the latter.) 178 The Designated Expert when deliberating on whether to include a new 179 parameter in the tel URI registry may use the criteria provided below 180 to reach a decision (this is not an exhaustive list but 181 representative of the issues to consider when rendering an equitable 182 decision): 184 o If the tel URI -- with the parameter under consideration -- will 185 be converted to a URI used by other signaling protocols such as 186 the Session Initiation Protocol (SIP [4]) or H.323 [7], then the 187 expert must consider whether this parameter merely encapsulates 188 signaling information that is not meaningful to the processing of 189 requests in the domain of the converted URI. For example, certain 190 Integrated Services Digital Network (ISDN) User Part (ISUP, [8]) 191 parameters have no equivalent corollary in SIP; thus their 192 presence or absence in a SIP URI will not hinder the normal rules 193 for processing that URI. Other parameters may affect the normal 194 processing rules associated with the URI; in such cases, the 195 expert must consider carefully the ramifications, if any, of the 196 presence of such parameters. 198 o Certain parameters of a tel URI can be optional. These parameters 199 act as metadata about the identifier in the tel URI. Optional 200 parameters should provide additional information to a service for 201 which they apply instead of acting as enablers of that service in 202 the first place. The service must continue to be invoked and 203 operate normally even in the absence of these parameters. 205 5. Security Considerations 207 The registry in this document does not in itself have security 208 considerations. However, as mentioned in [3], an important reason 209 for the IETF to manage the extensions of SIP is to ensure that all 210 extensions and parameters are able to provide secure usage. The 211 supporting RFC publications for parameter registrations described 212 this specification MUST provide detailed security considerations for 213 them. 215 6. Acknowledgments 217 The structure of this document comes from [5], which is the 218 equivalent work done in the SIP domain to establish a registry. Ted 219 Hardie, Jon Peterson and Jonathan Rosenberg provided substantive 220 comments that have improved this document. 222 7. References 224 7.1. Normative References 226 [1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 227 December 2004. 229 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 230 Levels", BCP 14, RFC 2119, March 1997. 232 7.2. Informative References 234 [3] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 235 Rosen, "Change Process for the Session Initiation Protocol 236 (SIP)", BCP 67, RFC 3427, December 2002. 238 [4] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 239 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 240 Session Initiation Protocol", RFC 3261, June 2002. 242 [5] Camarillo, G., "The Internet Assigned Number Authority (IANA) 243 Uniform Resource Identifier (URI) Parameter Registry for the 244 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 245 December 2004. 247 [6] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 248 Considerations Section in RFCs", 249 draft-narten-iana-considerations-rfc2434bis-08 (work in 250 progress), October 2007. 252 [7] ITU-T H.323, "H.323: Packet-based multimedia communications 253 systems", June 2006. 255 [8] ITU-T Q.764, "Signaling System No. 7: ISDN User Part Signaling 256 Procedures", December 1999. 258 Authors' Addresses 260 Cullen Jennings 261 Cisco Systems 262 170 West Tasman Drive 263 Mailstop SJC-21/2 264 San Jose, CA 95134 265 USA 267 Phone: +1 408 902-3341 268 Email: fluffy@cisco.com 270 Vijay K. Gurbani 271 Bell Laboratories, Alcatel-Lucent 272 2701 Lucent Lane 273 Room 9F-546 274 Lisle, IL 60532 275 USA 277 Phone: +1 630 224-0216 278 Email: vkg@alcatel-lucent.com 280 Full Copyright Statement 282 Copyright (C) The IETF Trust (2008). 284 This document is subject to the rights, licenses and restrictions 285 contained in BCP 78, and except as set forth therein, the authors 286 retain all their rights. 288 This document and the information contained herein are provided on an 289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 291 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 292 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 293 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 296 Intellectual Property 298 The IETF takes no position regarding the validity or scope of any 299 Intellectual Property Rights or other rights that might be claimed to 300 pertain to the implementation or use of the technology described in 301 this document or the extent to which any license under such rights 302 might or might not be available; nor does it represent that it has 303 made any independent effort to identify any such rights. Information 304 on the procedures with respect to rights in RFC documents can be 305 found in BCP 78 and BCP 79. 307 Copies of IPR disclosures made to the IETF Secretariat and any 308 assurances of licenses to be made available, or the result of an 309 attempt made to obtain a general license or permission for the use of 310 such proprietary rights by implementers or users of this 311 specification can be obtained from the IETF on-line IPR repository at 312 http://www.ietf.org/ipr. 314 The IETF invites any interested party to bring to its attention any 315 copyrights, patents or patent applications, or other proprietary 316 rights that may cover technology that may be required to implement 317 this standard. Please address the information to the IETF at 318 ietf-ipr@ietf.org. 320 Acknowledgment 322 Funding for the RFC Editor function is provided by the IETF 323 Administrative Support Activity (IASA).