idnits 2.17.1 draft-smith-oma-urn-00.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 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 302. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 286. ** 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 (July 2005) is 6859 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) -- Obsolete informational reference (is this intentional?): RFC 2141 (Obsoleted by RFC 8141) -- Obsolete informational reference (is this intentional?): RFC 3406 (Obsoleted by RFC 8141) Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft D. Smith 2 Document: draft-smith-oma-urn-00.txt Open Mobile Alliance 3 Expires: January 2006 July 2005 5 A Uniform Resource Name (URN) Namespace for 6 the Open Mobile Alliance (OMA) 8 Status of this Memo 10 By submitting this Internet-Draft, each author represents that any 11 applicable patent or other IPR claims of which he or she is aware 12 have been or will be disclosed, and any of which he or she becomes 13 aware will be disclosed, in accordance with Section 6 of BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt 27 The list of Internet-Draft Shadow Directories can be accessed at 28 http://www.ietf.org/shadow.html. 30 Abstract 32 This document describes the Namespace Identifier (NID) for Uniform 33 Resource Namespace (URN) resources published by the Open Mobile 34 Alliance (OMA). OMA defines and manages resources that utilize this 35 URN name model. Management activities for these and other resource 36 types are provided by the Open Mobile Naming Authority (OMNA). 38 Table of Contents 40 1. Introduction...................................................2 41 2. URN Specification for "oma" NID................................3 42 2.1 Namespace ID:..............................................3 43 2.2 Registration Information:..................................3 44 2.3 Declared registrant of the namespace:......................3 45 2.4 Declaration of syntactic structure:........................3 46 2.5 Relevant ancillary documentation:..........................3 47 2.6 Identifier uniqueness considerations:......................4 48 2.7 Identifier persistence considerations:.....................4 49 2.8 Process of identifier assignment:..........................4 50 2.9 Process for identifier resolution:.........................4 51 2.10 Rules for Lexical Equivalence:............................4 52 2.11 Conformance with URN Syntax:..............................4 53 2.12 Validation mechanism:.....................................4 54 2.13 Scope:....................................................5 55 3. Examples.......................................................5 56 4. Namespace Considerations.......................................5 57 5. Community Considerations.......................................5 58 6. Security Considerations........................................6 59 7. IANA Considerations............................................6 60 8. References.....................................................6 61 8.2 Normative References.......................................6 62 8.3 Informative References.....................................6 63 Author's Address..................................................6 64 Intellectual Property Statement...................................7 65 Full Copyright Statement..........................................7 67 1. Introduction 69 OMA is a specification development body developing technologies for 70 mobile devices. This activity is supported by a membership comprised 71 of network operators, equipment vendors, content providers and other 72 suppliers to the mobile market. 74 Some of the technologies being developed by OMA need XML namespaces 75 that are managed so that they are unique and persistent. To assure 76 that the uniqueness is absolute, the registration of a specific NID 77 for use by OMA was deemed appropriate. Therefore, a full and 78 complete registration will follow the namespace specification process 79 as defined in [RFC3406]. 81 2. URN Specification for "oma" NID 83 2.1 Namespace ID: 85 The NID "oma" is requested. 87 2.2 Registration Information: 89 registration version number: 1 90 registration date: 2005-07-18 92 2.3 Declared registrant of the namespace: 94 Registering organization 95 Name: Open Mobile Alliance 96 Address: 4275 Executive Square 97 Suite 240s 98 La Jolla, CA 92037 100 Designated contact 101 Role: Technical Program Manager 102 Email: TPM@omaorg.org 104 2.4 Declaration of syntactic structure: 106 The Namespace Specific String (NSS) of all URNs that use the "oma" 107 NID will have the following structure: 109 urn:oma:{OMAresource}:{ResourceSpecificString} 111 where the "OMAresource" is a US-ASCII string that conforms to the URN 112 syntax requirements [RFC2141] and defines a specific class of 113 resource type. Each resource type has a specific labeling scheme 114 that is covered by "ResourceSpecificString" which also conforms to 115 the naming requirements of [RFC2141]. 117 OMA maintains a naming authority, the Open Mobile Naming Authority 118 (OMNA), that will manage the assignment of "OMAresources" and the 119 specific registration values assigned for each resource class. 121 2.5 Relevant ancillary documentation: 123 The Open Mobile Naming Authority (OMNA) provides information on the 124 registered resources and the registrations for each. More 125 information about OMNA and the registration activities and procedures 126 to be followed are available at: 128 http://www.openmobilealliance.org/tech/omna 130 2.6 Identifier uniqueness considerations: 132 The OMNA will manage resources using the "oma" NID and will be the 133 authority for managing the resources and subsequent strings 134 associated. In the associated procedures, OMNA will ensure the 135 uniqueness of the strings themselves or shall permit secondary 136 responsibility for management of well-defined sub-trees. 138 OMA may permit use of experimental type values that will not be 139 registered. As a consequence, multiple users may end up using the 140 same value for separate uses. As experimental usage is only intended 141 for testing purposes, this should not be a real issue. 143 2.7 Identifier persistence considerations: 145 OMNA will provide clear documentation of the registered uses of the 146 "oma" NID. This will be structured such that each OMAresource will 147 have a separate description and registration table. 149 The registration tables and information will be published and 150 maintained by OMNA on its web site. 152 2.8 Process of identifier assignment: 154 OMNA will provide procedures for registration of each type of 155 resource that it maintains. Each such resource may have three types 156 of registration activities: 158 1) Registered values associated with OMA specs or services 159 2) Registration of values or sub-trees to other entities 160 3) Name models for use in experimental purposes 162 2.9 Process for identifier resolution: 164 The namespace is not listed with an RDS; this is not relevant. 166 2.10 Rules for Lexical Equivalence: 168 No special considerations, the rules for lexical equivalence of 169 [RFC2141] apply. 171 2.11 Conformance with URN Syntax: 173 No special considerations. 175 2.12 Validation mechanism: 177 None specified. URN assignment will be handled by procedures 178 implemented in support of OMNA activities. 180 2.13 Scope: 182 Global 184 3. Examples 186 The following examples are representative urns that could be assigned 187 by OMNA. They may not be the actual strings that would be assigned. 189 urn:oma:ac:oma-presence 190 Defines the urn to be used for the Application Characteristic 191 object definition for providing attributes to the Presence enabler 192 defined in OMA. 194 urn:oma:drms:org-foobar 195 Defines the urn associated with the Digital Rights Management 196 System object definition allocated to foobar which is an external 197 organization that made request via OMNA for a drms urn. 199 4. Namespace Considerations 201 The Open Mobile Alliance is developing a variety of application and 202 service enablers. Some of these enablers depend upon supporting 203 information (e.g. data descriptions, attributes, etc.) to be fully 204 specified. For proper operation, descriptions of the needed 205 supporting information must exist and be available in a unique, 206 reliable and persistent manner. These dependencies provide the basis 207 of need for namespaces, in one form or another. 209 As the Open Mobile Alliance work is ongoing and covers many technical 210 areas, the possibility of binding to various other namespace 211 repositories has been deemed impractical. Each object or 212 description, as defined in OMA, could possibly be related to multiple 213 different other namespaces so further conflicts of association could 214 occur. Thus the intent is to utilize the Open Mobile Naming 215 Authority, operated by OMA, as the naming authority for OMA defined 216 objects and descriptions. 218 5. Community Considerations 220 The objects and descriptions required for enablers produced by OMA 221 are generally available for use by other organizations. The Open 222 Mobile Naming Authority will provide access and support for name 223 requests by these organizations. This support can be enabled in 224 timely and responsive fashion as new objects and descriptions are 225 produced. These will be enabled in a fashion similar to current OMNA 226 support. 228 6. Security Considerations 230 There are no additional security considerations other than those 231 normally associated with the use and resolution of URNs in general. 233 7. IANA Considerations 235 The objective of this registration is for the requested NID to be 236 entered into the IANA registry for URN NIDs. This would result in an 237 update to http://www.iana.org/assignments/urn-namespaces and any 238 associated mirrors. 240 8. References 242 8.2 Normative References 244 As this registration request is an informative document, there are no 245 normative references. 247 8.3 Informative References 249 [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 251 [RFC3406] Daigle, L., van Gulik, D., Iannella, R. and P. Faltstrom, 252 "Uniform Resource Names (URN) Namespace Definition 253 Mechanisms", BCP 66, RFC 3406, October 2002. 255 Author's Address 257 Dwight Smith 258 Role: Chair, Operations and Process Committee, OMA 259 Address: Motorola 260 5555 N Beach Street 261 Ft. Worth, TX 76137 262 Email: dwight.smith@motorola.com 264 Intellectual Property Statement 266 The IETF takes no position regarding the validity or scope of any 267 Intellectual Property Rights or other rights that might be claimed to 268 pertain to the implementation or use of the technology described in 269 this document or the extent to which any license under such rights 270 might or might not be available; nor does it represent that it has 271 made any independent effort to identify any such rights. Information 272 on the procedures with respect to rights in RFC documents can be 273 found in BCP 78 and BCP 79. 275 Copies of IPR disclosures made to the IETF Secretariat and any 276 assurances of licenses to be made available, or the result of an 277 attempt made to obtain a general license or permission for the use of 278 such proprietary rights by implementers or users of this 279 specification can be obtained from the IETF on-line IPR repository at 280 http://www.ietf.org/ipr. 282 The IETF invites any interested party to bring to its attention any 283 copyrights, patents or patent applications, or other proprietary 284 rights that may cover technology that may be required to implement 285 this standard. Please address the information to the IETF at 286 ietf-ipr@ietf.org. 288 Full Copyright Statement 290 Copyright (C) The Internet Society (2005). 292 This document is subject to the rights, licenses and restrictions 293 contained in BCP 78, and except as set forth therein, the authors 294 retain all their rights. 296 This document and the information contained herein are provided on an 297 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 298 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 299 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 300 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 301 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 302 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.