idnits 2.17.1 draft-monrad-sipping-3gpp-urn-namespace-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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 302. 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 (Jun 06, 2008) is 5803 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3406 (Obsoleted by RFC 8141) ** Obsolete normative reference: RFC 2141 (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 SIPPING Working Group A. Monrad 3 Internet-Draft S. Loreto 4 Intended status: Informational Ericsson 5 Expires: December 8, 2008 Jun 06, 2008 7 A Uniform Resource Name (URN) Namespace for the 3rd Generation 8 Partnership Project (3GPP) 9 draft-monrad-sipping-3gpp-urn-namespace-03.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 8, 2008. 36 Abstract 38 This document describes the Namespace Identifier (NID) for Uniform 39 Resource Namespace (URN) resources published by the 3rd Generation 40 Partnership Project (3GPP). 3GPP defines and manages resources that 41 utilize this URN name model. Management activities for these and 42 other resource types are provided by the 3GPP Support Team. 44 Table of Contents 46 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 47 2. URN Specification for the 3GPP Namespace Identifier (NID) . . . 3 48 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 49 4. Namespace Considerations . . . . . . . . . . . . . . . . . . . 6 50 5. Community Considerations . . . . . . . . . . . . . . . . . . . 6 51 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 52 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 53 8. Normative References . . . . . . . . . . . . . . . . . . . . . 7 54 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 55 Intellectual Property and Copyright Statements . . . . . . . . . . 8 57 1. Introduction 59 3GPP is a cooperation of international telecommunication standards 60 bodies developing technologies for cellular networks. This activity 61 is supported by a membership composed of network operators, equipment 62 vendors, content providers, and other suppliers to the mobile market. 64 Some of the technologies being developed by 3GPP need URN namespaces 65 that are managed so that they are unique and persistent. To assure 66 that the uniqueness is absolute, the registration of a specific NID 67 for use by 3GPP was deemed appropriate. Therefore, a full and 68 complete registration will follow the namespace specification process 69 as defined in RFC 3406 [RFC3406]. 71 2. URN Specification for the 3GPP Namespace Identifier (NID) 73 Namespace ID: 75 The NID "3gpp" is requested. 77 Registration Information: 79 registration version number: 1 80 registration date: 2007-11-16 82 Declared registrant of the namespace: 84 Registering organization 85 Name: 3rd Generation Partnership Project 86 Address: ETSI 87 Mobile Competence Centre 88 650, route des Luciole 89 06921 Sophia-Antipolis Cedex 90 France 92 Designated contact 93 Role: Specifications Manager 94 Email: john.meredith@etsi.org 96 Declaration of syntactic structure: 98 The Namespace Specific String (NSS) of all URNs that use the 99 "3gpp" NID will have the following structure: 101 urn:3gpp:{3gpp-urn} 103 where the "3gpp-urn" is a US-ASCII string that conforms to the 104 NSS(Namespace Specific String) Syntax described in RFC2141 105 [RFC2141] and defines a specific resource type. 107 Relevant ancillary documentation: 109 3GPP provides information on registration for each URN. More 110 information about 3GPP and the registration activities and 111 procedures to be followed are available at: 113 http://www.3gpp.org/tb/Other/URN/URN.htm 115 Identifier uniqueness considerations: 117 3GPP will manage resources using the "3gpp" NID and will be the 118 authority for managing the "3gpp-urn" strings. In the associated 119 procedures, 3GPP will ensure the uniqueness of the strings 120 themselves or shall permit secondary responsibility for management 121 of well-defined sub-trees. 123 3GPP may permit use of experimental type values that will not be 124 registered. As a consequence, multiple users may end up using the 125 same value for separate uses. As experimental usage is only 126 intended for testing purposes, this should not be a real issue. 128 Identifier persistence considerations: 130 3GPP will provide clear documentation of the registered uses of 131 the "3gpp" NID. This will be structured such that each "3gpp- 132 urn", if needed, will have a separate description and registration 133 table. 135 The registration tables and information will be published and 136 maintained by 3GPP on its web site. 138 Process of identifier assignment: 140 3GPP will provide procedures for registration of each type of 141 resource that it maintains. Each such resource may have three 142 types of registration activities: 144 1. Registered values associated with 3GPP spec or services 145 2. Registration of values or sub-trees to other entities 146 3. Name models for use in experimental purposes 148 New Namespace Identifier (NID) labels 149 The Entries in the registration table will be the following: 151 3gpp-urn: the registered value; 152 Description: description of the registered vaulue; 153 Reference: 3GPP spec that defines the value; 154 Contact: person requesting the URN assignment. 156 Process for identifier resolution: 158 The namespace is not listed with a Resolution Discovery System 159 (RDS); as this is not relevant. 161 Rules for Lexical Equivalence: 163 No special considerations; the rules for lexical equivalence of 164 RFC 2141 [RFC2141] apply. 166 Conformance with URN Syntax: 168 No special considerations. 170 Validation mechanism: 172 None specified. URN assignment will be handled by procedures 173 supported and maintained by 3GPP. 175 Scope: 177 Global 179 3. Examples 181 The following examples are representative urns that could be assigned 182 by 3GPP. They are not actual strings that are assigned. 184 urn:3gpp:featurephones 186 Defines the "3gpp-urn" to be used for "featurephones". 188 urn:3gpp:acme.foo-serv 190 Defines the urn associated with the operator identified by the 191 "3gpp-urn" value "acme", which has decided to register and provide 192 information about its service identified by value "foo-serv". 194 4. Namespace Considerations 196 The 3rd Generation Partnership Project is developing a variety of 197 enablers and applications. Some of these require information to be 198 fully specified. 200 For proper operation, descriptions of the needed information must 201 exist For the URNs and be available in a unique, reliable, and 202 persistent manner. 204 As 3GPP is ongoing and covers many technical areas, the possibility 205 of binding to various other namespace repositories has been deemed 206 impractical. Each object or description, as defined in 3GPP, could 207 possibly be related to multiple different other namespaces, so 208 further conflicts of association could occur. Thus the intent is to 209 utilize the 3GPP specifications manager as the naming authority for 210 3GPP-defined URNs and its descriptions. 212 5. Community Considerations 214 The objects and descriptions required for enablers produced by 3GPP 215 are generally available for use by other organizations. The 3rd 216 Generation Partnership Project Support Office will provide access and 217 support for name requests by these organizations. This support can 218 be enabled in a timely and responsive fashion as new objects and 219 descriptions are produced. 221 6. Security Considerations 223 There are no additional security considerations other than those 224 normally associated with the use and resolution of URNs in general. 226 7. IANA Considerations 228 This section register a new URN NID with the registration provided in 229 Section 2. 231 The update can be found at: 232 http://www.iana.org/assignments/urn-namespaces and any associated 233 mirrors. 235 "3gpp-urn" strings are identified by label managed by 3GPP. Thus, 236 creating a new label does not require any IANA action. 238 8. Normative References 240 [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, 241 "Uniform Resource Names (URN) Namespace Definition 242 Mechanisms", BCP 66, RFC 3406, October 2002. 244 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 246 Authors' Addresses 248 Atle Monrad 249 Ericsson 250 Televeien 1 251 Grimstad 4898 252 Norway 254 Email: atle.monrad@ericsson.com 256 Salvatore Loreto 257 Ericsson 258 Hirsalantie 11 259 Jorvas 02420 260 Finland 262 Email: Salvatore.Loreto@ericsson.com 264 Full Copyright Statement 266 Copyright (C) The IETF Trust (2008). 268 This document is subject to the rights, licenses and restrictions 269 contained in BCP 78, and except as set forth therein, the authors 270 retain all their rights. 272 This document and the information contained herein are provided on an 273 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 274 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 275 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 276 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 277 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 278 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 280 Intellectual Property 282 The IETF takes no position regarding the validity or scope of any 283 Intellectual Property Rights or other rights that might be claimed to 284 pertain to the implementation or use of the technology described in 285 this document or the extent to which any license under such rights 286 might or might not be available; nor does it represent that it has 287 made any independent effort to identify any such rights. Information 288 on the procedures with respect to rights in RFC documents can be 289 found in BCP 78 and BCP 79. 291 Copies of IPR disclosures made to the IETF Secretariat and any 292 assurances of licenses to be made available, or the result of an 293 attempt made to obtain a general license or permission for the use of 294 such proprietary rights by implementers or users of this 295 specification can be obtained from the IETF on-line IPR repository at 296 http://www.ietf.org/ipr. 298 The IETF invites any interested party to bring to its attention any 299 copyrights, patents or patent applications, or other proprietary 300 rights that may cover technology that may be required to implement 301 this standard. Please address the information to the IETF at 302 ietf-ipr@ietf.org.