idnits 2.17.1 draft-ietf-iptel-tel-reg-06.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 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 298. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 309. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 316. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 322. 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 : ---------------------------------------------------------------------------- -- The draft header indicates that this document updates RFC3966, but the abstract doesn't seem to mention this, which it should. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year (Using the creation date from RFC3966, updated by this document, for RFC5378 checks: 2003-06-24) -- 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 (June 19, 2008) is 5790 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 162 -- Looks like a reference, but probably isn't: 'RFC 4715' on line 160 -- Looks like a reference, but probably isn't: 'RFC 4759' on line 163 -- Looks like a reference, but probably isn't: 'RFC 4694' on line 168 -- Looks like a reference, but probably isn't: 'RFC 4904' on line 170 ** Obsolete normative reference: RFC 5226 (ref. '3') (Obsoleted by RFC 8126) -- Obsolete informational reference (is this intentional?): RFC 3427 (ref. '4') (Obsoleted by RFC 5727) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 14 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 Updates: 3966 (if approved) V. Gurbani 5 Intended status: Best Current Bell Laboratories, Alcatel-Lucent 6 Practice June 19, 2008 7 Expires: December 21, 2008 9 The Internet Assigned Number Authority (IANA) tel Uniform Resource 10 Identifier (URI) Parameter Registry 11 draft-ietf-iptel-tel-reg-06 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on December 21, 2008. 38 Copyright Notice 40 Copyright (C) The IETF Trust (2008). 42 Abstract 44 This document creates an Internet Assigned Number Authority (IANA) 45 registry for tel Uniform Resource Identifier (URI) parameters and 46 their values. It populates the registry with the parameters defined 47 in the tel URI specification, along with the parameters in tel URI 48 extensions defined for number portability and trunk groups. 50 Table of Contents 52 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Use of the Registry . . . . . . . . . . . . . . . . . . . . . . 3 55 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 56 4.1. tel URI Parameters Registry . . . . . . . . . . . . . . . . 4 57 4.2. Registration Policy for tel URI Parameters . . . . . . . . 5 58 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 62 7.2. Informative References . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 64 Intellectual Property and Copyright Statements . . . . . . . . . . 8 66 1. Introduction 68 The tel URI (RFC3966 [1]), defines a URI that can be used to 69 represent resources identified by telephone numbers. The tel URI, 70 like many other URIs, provides extensibility through the definition 71 of new URI parameters and new values for existing parameters. 72 However, RFC3966 did not specify an IANA registry where such 73 parameters and values can be listed and standardized. This 74 specification creates such a registry. 76 2. Terminology 78 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 79 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 80 document are to be interpreted as described in [2]. 82 3. Use of the Registry 84 The tel URI parameters and values for these parameters MUST be 85 documented in a RFC or other permanent and readily available public 86 specification in order to be registered by IANA. This documentation 87 MUST fully explain the syntax, intended usage, and semantics of the 88 parameter. The intent of this requirement is to assure 89 interoperability between independent implementations, and to prevent 90 accidental namespace collisions between implementations of dissimilar 91 features. 93 Documents defining tel URI parameters or parameter values MUST 94 register them with IANA as described in Section 4. The IANA 95 registration policy for such parameters is "Specification Required, 96 Designated Expert," and is further discussed in Section 4.2. 98 Some tel URI parameters only accept a set of predefined parameter 99 values while others can take any value. There are also parameters 100 that do not have any value; they are used as flags. 102 Those URI parameters that take on predefined values typically take on 103 a large number of values. Registering each of those values, or 104 creating a sub-registry for each such parameter is not appropriate. 105 Instead, we have chosen to register URI parameter values by 106 reference. That is, the entry in the URI parameter registry for a 107 given URI parameter contains references to the RFCs defining new 108 values of that parameter. 110 Accordingly, the tel URI parameter registry contains a column that 111 indicates whether or not each parameter accepts a value. The column 112 may contain "No value" or "Constrained". A "Constrained" in the 113 column implies that certain predefined values exist for this 114 parameter and the accompanying RFC or other permanent and readily 115 available public specification should be consulted to find out the 116 accepted set of values. A "No Value" in the column implies that the 117 parameter is used either as a flag, or does not have a set of 118 predefined values. The accompanying RFC or other permanent and 119 readily available public specification should provide more 120 information on the semantics of the parameter. 122 4. IANA Considerations 124 The specification creates a new IANA registry named "tel URI 125 Parameters". 127 4.1. tel URI Parameters Registry 129 New tel URI parameters and new values for existing tel URI parameters 130 MUST be registered with IANA. 132 When registering a new tel URI parameter the following information 133 MUST be provided: 135 o Name of the parameter. 137 o Whether the parameter only accepts a set of predefined values. 139 o Reference to the RFC or other permanent and readily available 140 public specification defining the parameter and new values. 142 When registering a new value for an existing tel URI parameter the 143 following information MUST be provided: 145 o Name of the parameter. 147 o Reference to the RFC or other permanent and readily available 148 public specification providing the new value. 150 Note to IANA editor: When a new value for an existing tel URI 151 parameter is standardized, the Reference column of Table 1 (below) 152 corresponding to the parameter name must be updated to include the 153 new RFC number. 155 Table 1 contains the initial values for this registry. 157 Parameter Name Predefined Values Reference 158 -------------- ----------------- --------- 159 isub Constrained [RFC 3966] 160 isub-encoding Constrained [RFC 4715] 161 ext Constrained [RFC 3966] 162 phone-context Constrained [RFC 3966] 163 enumdi No value [RFC 4759] 164 npdi No value [RFC 4694] 165 rn Constrained [RFC 4694] 166 rn-context Constrained [RFC 4694] 167 cic Constrained [RFC 4694] 168 cic-context Constrained [RFC 4694] 169 tgrp Constrained [RFC 4904] 170 trunk-context Constrained [RFC 4904] 172 Table 1: IANA tel URI parameter registry 174 4.2. Registration Policy for tel URI Parameters 176 As per the terminology in [3] and actions accorded to such a role, 177 the registration policy for tel URI parameters shall be 178 "Specification Required, Designated Expert" (the former implicitly 179 implies the latter.) 181 The Designated Expert when deliberating on whether to include a new 182 parameter in the tel URI registry may use the criteria provided below 183 to reach a decision (this is not an exhaustive list but 184 representative of the issues to consider when rendering an equitable 185 decision): 187 o If the tel URI -- with the parameter under consideration -- will 188 be converted to a URI used by other signaling protocols such as 189 the Session Initiation Protocol (SIP [5]) or H.323 [7], then the 190 expert must consider whether this parameter merely encapsulates 191 signaling information that is not meaningful to the processing of 192 requests in the domain of the converted URI. For example, certain 193 Integrated Services Digital Network (ISDN) User Part (ISUP, [8]) 194 parameters have no equivalent corollary in SIP; thus their 195 presence or absence in a SIP URI will not hinder the normal rules 196 for processing that URI. Other parameters may affect the normal 197 processing rules associated with the URI; in such cases, the 198 expert must consider carefully the ramifications, if any, of the 199 presence of such parameters. 201 o Certain parameters of a tel URI can be optional. These parameters 202 act as metadata about the identifier in the tel URI. Optional 203 parameters should provide additional information to a service for 204 which they apply instead of acting as enablers of that service in 205 the first place. The service must continue to be invoked and 206 operate normally even in the absence of these parameters. 208 5. Security Considerations 210 The registry in this document does not in itself have security 211 considerations. However, as mentioned in [4], an important reason 212 for the IETF to manage the extensions of SIP is to ensure that all 213 extensions and parameters are able to provide secure usage. The 214 supporting RFC publications for parameter registrations described in 215 this specification MUST provide detailed security considerations for 216 them. 218 6. Acknowledgments 220 The structure of this document comes from [6], which is the 221 equivalent work done in the SIP domain to establish a registry. Ted 222 Hardie, Alfred Hoenes, Jon Peterson and Jonathan Rosenberg provided 223 substantive comments that have improved this document. 225 Brian Carpenter, Lars Eggert, Pasi Eronen, Chris Newman, and Glen 226 Zorn provided feedback during IESG review and Gen-ART review. 228 7. References 230 7.1. Normative References 232 [1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 233 December 2004. 235 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 236 Levels", BCP 14, RFC 2119, March 1997. 238 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 239 Considerations Section in RFCs", BCP 26, RFC 5226, May 2008. 241 7.2. Informative References 243 [4] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 244 Rosen, "Change Process for the Session Initiation Protocol 245 (SIP)", BCP 67, RFC 3427, December 2002. 247 [5] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 248 Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: 249 Session Initiation Protocol", RFC 3261, June 2002. 251 [6] Camarillo, G., "The Internet Assigned Number Authority (IANA) 252 Uniform Resource Identifier (URI) Parameter Registry for the 253 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 254 December 2004. 256 [7] ITU-T H.323, "H.323: Packet-based multimedia communications 257 systems", June 2006. 259 [8] ITU-T Q.764, "Signaling System No. 7: ISDN User Part Signaling 260 Procedures", December 1999. 262 Authors' Addresses 264 Cullen Jennings 265 Cisco Systems 266 170 West Tasman Drive 267 Mailstop SJC-21/2 268 San Jose, CA 95134 269 USA 271 Phone: +1 408 902-3341 272 Email: fluffy@cisco.com 274 Vijay K. Gurbani 275 Bell Laboratories, Alcatel-Lucent 276 2701 Lucent Lane 277 Room 9F-546 278 Lisle, IL 60532 279 USA 281 Phone: +1 630 224-0216 282 Email: vkg@alcatel-lucent.com 284 Full Copyright Statement 286 Copyright (C) The IETF Trust (2008). 288 This document is subject to the rights, licenses and restrictions 289 contained in BCP 78, and except as set forth therein, the authors 290 retain all their rights. 292 This document and the information contained herein are provided on an 293 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 294 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 295 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 296 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 297 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 298 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 300 Intellectual Property 302 The IETF takes no position regarding the validity or scope of any 303 Intellectual Property Rights or other rights that might be claimed to 304 pertain to the implementation or use of the technology described in 305 this document or the extent to which any license under such rights 306 might or might not be available; nor does it represent that it has 307 made any independent effort to identify any such rights. Information 308 on the procedures with respect to rights in RFC documents can be 309 found in BCP 78 and BCP 79. 311 Copies of IPR disclosures made to the IETF Secretariat and any 312 assurances of licenses to be made available, or the result of an 313 attempt made to obtain a general license or permission for the use of 314 such proprietary rights by implementers or users of this 315 specification can be obtained from the IETF on-line IPR repository at 316 http://www.ietf.org/ipr. 318 The IETF invites any interested party to bring to its attention any 319 copyrights, patents or patent applications, or other proprietary 320 rights that may cover technology that may be required to implement 321 this standard. Please address the information to the IETF at 322 ietf-ipr@ietf.org. 324 Acknowledgment 326 Funding for the RFC Editor function is provided by the IETF 327 Administrative Support Activity (IASA).