idnits 2.17.1 draft-jennings-iptel-tel-reg-01.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 261. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 238. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 251. ** 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (Dec 05, 2005) is 6717 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 136 -- Looks like a reference, but probably isn't: 'RFC AAAA' on line 137 -- Looks like a reference, but probably isn't: 'RFC BBBB' on line 142 -- Looks like a reference, but probably isn't: 'RFC CCCC' on line 144 ** Obsolete normative reference: RFC 2434 (ref. '3') (Obsoleted by RFC 5226) == Outdated reference: A later version (-10) exists of draft-ietf-iptel-trunk-group-04 == Outdated reference: A later version (-11) exists of draft-ietf-iptel-tel-np-07 == Outdated reference: A later version (-05) exists of draft-ietf-iptel-tel-enumdi-01 Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 11 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 Expires: June 8, 2006 V. Gurbani 5 Lucent Technologies, Inc./Bell 6 Laboratories 7 Dec 05, 2005 9 The Internet Assigned Number Authority (IANA) tel Uniform Resource 10 Identifier (URI) Parameter Registry 11 draft-jennings-iptel-tel-reg-01 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 June 8, 2006. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 This document creates an Internet Assigned Number Authority (IANA) 45 registry for the tel Uniform Resource Identifier (URI) parameters, 46 and their values. It also lists the already existing parameters to 47 be used as initial values for that registry. 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 . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . 5 58 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 5 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 7.1 Normative References . . . . . . . . . . . . . . . . . . . 5 61 7.2 Informative References . . . . . . . . . . . . . . . . . . 5 62 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 6 63 Intellectual Property and Copyright Statements . . . . . . . . 7 65 1. Introduction 67 RFC 3966 [1] allows new tel URI parameters, and new parameter values 68 to be defined. However, RFC 3966 omitted an IANA registry for them. 69 This specification creates such a registry. 71 2. Terminology 73 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 74 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 75 document are to be interpreted as described in RFC 2119 [2]. 77 3. Use of the Registry 79 The tel URI parameters and values for these parameters MUST be 80 documented in a standards-track RFC in order to be registered by 81 IANA. This documentation MUST fully explain the syntax, intended 82 usage, and semantics of the parameter. The intent of this 83 requirement is to assure interoperability between independent 84 implementations, and to prevent accidental namespace collisions 85 between implementations of dissimilar features. 87 RFCs defining tel URI parameters, or parameter values MUST register 88 them with IANA as described below. 90 Registered tel URI parameters and their values are to be considered 91 "reserved words". In order to preserve interoperability, registered 92 parameters MUST be used in a manner consistent with that described in 93 their defining RFC. Implementations MUST NOT utilize "private" or 94 "locally defined" URI parameters that conflict with registered 95 parameters. 97 Some tel URI parameters only accept a set of predefined parameter 98 values while others can take any value. There are also parameters 99 that can not have any value. Registering all parameter values for 100 all tel URI parameters of this type would require a large number of 101 sub-registries. Instead, we have chosen to register URI parameter 102 values by reference. That is, the entry in the URI parameter 103 registry for a given URI parameter contains references to the RFCs 104 defining new values of that parameter. 106 The tel URI parameter registry contains a column that indicates 107 whether or not each parameter only accepts a set of predefined 108 values. The column can contain Yes, No, or NA. Implementers of 109 parameters with a "yes" in that column need to find all the valid 110 parameter values in the RFCs provided as references. Parameters that 111 are not allowed to have a parameters have a value of "NA". 113 4. IANA Considerations 115 The specification creates a new IANA registry named "tel URI 116 Parameters". 118 4.1 tel URI Parameters Registry 120 New tel URI parameters and new parameter values are registered by the 121 IANA. When registering a new tel parameter or a new value for a 122 parameter, the following information MUST be provided. 124 o Name of the parameter. 125 o Whether the parameter only accepts a set of predefined values. If 126 the parameter does not allow any value, this field is marked as 127 "NA". 128 o Reference to the RFC defining the parameter and to any RFC that 129 defines new values for the parameter. 131 Table 1 contains the initial values for this registry. 133 Parameter Name Predefined Values Reference 134 -------------- ----------------- --------- 135 isub Yes [RFC 3966] 136 ext Yes [RFC 3966] 137 enumdi NA [RFC AAAA] 138 npdi NA [RFC BBBB] 139 rn Yes [RFC BBBB] 140 rn-context Yes [RFC BBBB] 141 cic Yes [RFC BBBB] 142 cic-context Yes [RFC BBBB] 143 tgrp Yes [RFC CCCC] 144 trunk-context Yes [RFC CCCC] 146 Table 1: IANA tel URI parameter registry 148 Note to RFC Editor: Please replace AAAA with the RFC number for [6]. 149 Please replace BBBB with the RFC number for [5]. Please replace CCCC 150 with the RFC number for [4]. 152 4.2 Registration Policy for tel URI Parameters 154 As per the terminology in RFC 2434 [3], the registration policy for 155 tel URI parameters shall be "Specification Required". 157 For the purposes of this registry, the parameter for which IANA 158 registration is requested MUST be defined by a standards-track RFC. 160 5. Security Considerations 162 The registry in this document does not in itself have security 163 considerations. However, as mentioned in RFC 3427, an important 164 reason for the IETF to manage the extensions of SIP is to ensure that 165 all extensions and parameters are able to provide secure usage. The 166 supporting RFC publications for parameter registrations described 167 this specification MUST provide detailed security considerations for 168 them. 170 6. Acknowledgments 172 The bulk of this document comes from RFC 3969 [7] written by Gonzalo 173 Camarillo. 175 7. References 177 7.1 Normative References 179 [1] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966, 180 December 2004. 182 [2] Bradner, S., "Key words for use in RFCs to Indicate Requirement 183 Levels", BCP 14, RFC 2119, March 1997. 185 [3] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA 186 Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. 188 [4] Jennings, C. and V. Gurbani, "Representing trunk groups in tel/ 189 sip Uniform Resource Identifiers (URIs)", 190 draft-ietf-iptel-trunk-group-04 (work in progress), May 2005. 192 [5] Yu, J., "New Parameters for the "tel" URI to Support Number 193 Portability", draft-ietf-iptel-tel-np-07 (work in progress), 194 July 2005. 196 [6] Stastny, R., "The ENUM Dip Indicator parameter for the "tel" 197 URI", draft-ietf-iptel-tel-enumdi-01 (work in progress), 198 April 2005. 200 7.2 Informative References 202 [7] Camarillo, G., "The Internet Assigned Number Authority (IANA) 203 Uniform Resource Identifier (URI) Parameter Registry for the 204 Session Initiation Protocol (SIP)", BCP 99, RFC 3969, 205 December 2004. 207 Authors' Addresses 209 Cullen Jennings 210 Cisco Systems 211 170 West Tasman Drive 212 Mailstop SJC-21/2 213 San Jose, CA 95134 214 USA 216 Phone: +1 408 902-3341 217 Email: fluffy@cisco.com 219 Vijay K. Gurbani 220 Lucent Technologies, Inc./Bell Laboratories 221 2000 Lucent Lane 222 Room 6G-440 223 Naperville, IL 60532 224 USA 226 Phone: +1 630 224-0216 227 Email: vkg@lucent.com 229 Intellectual Property Statement 231 The IETF takes no position regarding the validity or scope of any 232 Intellectual Property Rights or other rights that might be claimed to 233 pertain to the implementation or use of the technology described in 234 this document or the extent to which any license under such rights 235 might or might not be available; nor does it represent that it has 236 made any independent effort to identify any such rights. Information 237 on the procedures with respect to rights in RFC documents can be 238 found in BCP 78 and BCP 79. 240 Copies of IPR disclosures made to the IETF Secretariat and any 241 assurances of licenses to be made available, or the result of an 242 attempt made to obtain a general license or permission for the use of 243 such proprietary rights by implementers or users of this 244 specification can be obtained from the IETF on-line IPR repository at 245 http://www.ietf.org/ipr. 247 The IETF invites any interested party to bring to its attention any 248 copyrights, patents or patent applications, or other proprietary 249 rights that may cover technology that may be required to implement 250 this standard. Please address the information to the IETF at 251 ietf-ipr@ietf.org. 253 Disclaimer of Validity 255 This document and the information contained herein are provided on an 256 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 257 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 258 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 259 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 260 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 261 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 263 Copyright Statement 265 Copyright (C) The Internet Society (2005). This document is subject 266 to the rights, licenses and restrictions contained in BCP 78, and 267 except as set forth therein, the authors retain all their rights. 269 Acknowledgment 271 Funding for the RFC Editor function is currently provided by the 272 Internet Society.