idnits 2.17.1 draft-ietf-iptel-tel-reg-03.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 on line 287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 264. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 277. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 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 (November 27, 2006) is 6352 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (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 AAAA' on line 160 -- Looks like a reference, but probably isn't: 'RFC BBBB' on line 165 -- Looks like a reference, but probably isn't: 'RFC CCCC' on line 167 ** Obsolete normative reference: RFC 3427 (ref. '2') (Obsoleted by RFC 5727) ** Obsolete normative reference: RFC 2434 (ref. '4') (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-ietf-iptel-trunk-group-07 == Outdated reference: A later version (-11) exists of draft-ietf-iptel-tel-np-09 == Outdated reference: A later version (-05) exists of draft-ietf-iptel-tel-enumdi-03 Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 12 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,AAAA,BBBB,CCCC (if V. Gurbani 5 approved) Lucent Technologies, Inc./Bell 6 Expires: May 31, 2007 Laboratories 7 November 27, 2006 9 The Internet Assigned Number Authority (IANA) tel Uniform Resource 10 Identifier (URI) Parameter Registry 11 draft-ietf-iptel-tel-reg-03 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 May 31, 2007. 38 Copyright Notice 40 Copyright (C) The Internet Society (2006). 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 . . . . . . . . . . . . . . . . . . . 5 59 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 60 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 7.1 Normative References . . . . . . . . . . . . . . . . . . . 6 62 7.2 Informative References . . . . . . . . . . . . . . . . . . 6 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 64 Intellectual Property and Copyright Statements . . . . . . . . 8 66 1. Introduction 68 The tel URI, defined in RFC 3966 [1], defines a URI that can be used 69 to 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 RFC 2119 [3]. 82 3. Use of the Registry 84 The tel URI parameters and values for these parameters MUST be 85 documented in a standards-track RFC in order to be registered by 86 IANA. This documentation MUST fully explain the syntax, intended 87 usage, and semantics of the parameter. The intent of this 88 requirement is to assure interoperability between independent 89 implementations, and to prevent accidental namespace collisions 90 between implementations of dissimilar features. 92 RFCs defining tel URI parameters or parameter values MUST register 93 them with IANA as described below. 95 Registered tel URI parameters and their values are to be considered 96 "reserved words". In order to preserve interoperability, registered 97 parameters MUST be used in a manner consistent with that described in 98 their defining RFC. Implementations MUST NOT utilize "private" or 99 "locally defined" URI parameters that conflict with registered 100 parameters. 102 Some tel URI parameters only accept a set of predefined parameter 103 values while others can take any value. There are also parameters 104 that do not have any value; they are used as flags. 106 Those URI parameters that take on predefined values typically take on 107 a large number of values. Registering each of those values, or 108 creating a sub-registry for each such parameter is not not 109 appropriate. Instead, we have chosen to register URI parameter 110 values by reference. That is, the entry in the URI parameter 111 registry for a given URI parameter contains references to the RFCs 112 defining new values of that parameter. 114 Accordingly, the tel URI parameter registry contains a column that 115 indicates whether or not each parameter only accepts a set of 116 predefined values. The column can contain "Yes", or "No". A value 117 of "Yes" in the column implies that certain predefined values exist 118 for this parameter and the accompanying RFC should be consulted to 119 find out the accepted set of values. A value of "No" in the column 120 implies that the parameter is used either as a flag, or does not have 121 a set of predefined values. The accompanying RFC should provide more 122 information on the semantics of the parameter. 124 4. IANA Considerations 126 The specification creates a new IANA registry named "tel URI 127 Parameters". 129 4.1 tel URI Parameters Registry 131 New tel URI parameters and new values for existing tel URI parameters 132 MUST be registered by IANA. 134 When registering a new tel URI parameter the following information 135 MUST be provided: 137 o Name of the parameter. 138 o Whether the parameter only accepts a set of predefined values. 139 o Reference to the RFC defining the parameter and to any RFC that 140 defines new values for the parameter. 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. 146 o Reference to the RFC providing the new value. 148 Note to IANA editor: When a new value for an existing tel URI 149 parameter is standardized, the Reference column of Table 1 (below) 150 corresponding to the parameter name must be updated to include the 151 new RFC number. 153 Table 1 contains the initial values for this registry. 155 Parameter Name Predefined Values Reference 156 -------------- ----------------- --------- 157 isub Yes [RFC 3966] 158 ext Yes [RFC 3966] 159 phone-context Yes [RFC 3966] 160 enumdi No [RFC AAAA] 161 npdi No [RFC BBBB] 162 rn Yes [RFC BBBB] 163 rn-context Yes [RFC BBBB] 164 cic Yes [RFC BBBB] 165 cic-context Yes [RFC BBBB] 166 tgrp Yes [RFC CCCC] 167 trunk-context Yes [RFC CCCC] 169 Table 1: IANA tel URI parameter registry 171 Note to RFC Editor: Please replace AAAA with the RFC number for [7]. 172 Please replace BBBB with the RFC number for [6]. Please replace CCCC 173 with the RFC number for [5]. 175 4.2 Registration Policy for tel URI Parameters 177 As per the terminology in RFC 2434 [4], the registration policy for 178 tel URI parameters shall be "Standards Action". For the purposes of 179 this registry, the parameter for which IANA registration is requested 180 MUST be defined by a standards-track RFC. 182 5. Security Considerations 184 The registry in this document does not in itself have security 185 considerations. However, as mentioned in RFC 3427 [2], an important 186 reason for the IETF to manage the extensions of SIP is to ensure that 187 all extensions and parameters are able to provide secure usage. The 188 supporting RFC publications for parameter registrations described 189 this specification MUST provide detailed security considerations for 190 them. 192 6. Acknowledgments 194 The bulk of this document comes from RFC 3969 [8] written by Gonzalo 195 Camarillo. Jonathan Rosenberg provided substantive comments that 196 have improved this document. 198 7. References 199 7.1 Normative References 201 [1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 202 December 2004. 204 [2] Mankin, A., Bradner, S., Mahy, R., Willis, D., Ott, J., and B. 205 Rosen, "Change Process for the Session Initiation Protocol 206 (SIP)", RFC 3427, December 2002. 208 [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement 209 Levels", BCP 14, RFC 2119, March 1997. 211 [4] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 212 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 214 [5] Jennings, C. and V. Gurbani, "Representing trunk groups in tel/ 215 sip Uniform Resource Identifiers (URIs)", 216 draft-ietf-iptel-trunk-group-07 (work in progress), 217 December 2005. 219 [6] Yu, J., "New Parameters for the "tel" URI to Support Number 220 Portability", draft-ietf-iptel-tel-np-09 (work in progress), 221 July 2005. 223 [7] Stastny, R., "The ENUM Dip Indicator parameter for the "tel" 224 URI", draft-ietf-iptel-tel-enumdi-03 (work in progress), 225 April 2005. 227 7.2 Informative References 229 [8] Camarillo, G., "The Internet Assigned Number Authority (IANA) 230 Uniform Resource Identifier (URI) Parameter Registry for the 231 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 232 December 2004. 234 Authors' Addresses 236 Cullen Jennings 237 Cisco Systems 238 170 West Tasman Drive 239 Mailstop SJC-21/2 240 San Jose, CA 95134 241 USA 243 Phone: +1 408 902-3341 244 Email: fluffy@cisco.com 245 Vijay K. Gurbani 246 Lucent Technologies, Inc./Bell Laboratories 247 2701 Lucent Lane 248 Room 9F-546 249 Lisle, IL 60532 250 USA 252 Phone: +1 630 224-0216 253 Email: vkg@lucent.com 255 Intellectual Property Statement 257 The IETF takes no position regarding the validity or scope of any 258 Intellectual Property Rights or other rights that might be claimed to 259 pertain to the implementation or use of the technology described in 260 this document or the extent to which any license under such rights 261 might or might not be available; nor does it represent that it has 262 made any independent effort to identify any such rights. Information 263 on the procedures with respect to rights in RFC documents can be 264 found in BCP 78 and BCP 79. 266 Copies of IPR disclosures made to the IETF Secretariat and any 267 assurances of licenses to be made available, or the result of an 268 attempt made to obtain a general license or permission for the use of 269 such proprietary rights by implementers or users of this 270 specification can be obtained from the IETF on-line IPR repository at 271 http://www.ietf.org/ipr. 273 The IETF invites any interested party to bring to its attention any 274 copyrights, patents or patent applications, or other proprietary 275 rights that may cover technology that may be required to implement 276 this standard. Please address the information to the IETF at 277 ietf-ipr@ietf.org. 279 Disclaimer of Validity 281 This document and the information contained herein are provided on an 282 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 283 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 284 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 285 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 286 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 287 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 289 Copyright Statement 291 Copyright (C) The Internet Society (2006). This document is subject 292 to the rights, licenses and restrictions contained in BCP 78, and 293 except as set forth therein, the authors retain all their rights. 295 Acknowledgment 297 Funding for the RFC Editor function is currently provided by the 298 Internet Society.