You are here: irt.org | RFCs | RFC4358 [ previous next ]
Network Working Group D. Smith
Request for Comments: 4358 Open Mobile Alliance
Category: Informational January 2006
A Uniform Resource Name (URN) Namespace for
the Open Mobile Alliance (OMA)
Status of This Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes the Namespace Identifier (NID) for Uniform
Resource Namespace (URN) resources published by the Open Mobile
Alliance (OMA). OMA defines and manages resources that utilize this
URN name model. Management activities for these and other resource
types are provided by the Open Mobile Naming Authority (OMNA).
Table of Contents
1. Introduction ....................................................2
2. URN Specification for "oma" NID .................................2
3. Examples ........................................................4
4. Namespace Considerations ........................................4
5. Community Considerations ........................................5
6. Security Considerations .........................................5
7. IANA Considerations .............................................5
8. Informative References ..........................................5
Smith Informational [Page 1]
RFC 4358 URN Namespace for OMA January 2006 1. Introduction OMA is a specification development body developing technologies for mobile devices. This activity is supported by a membership composed of network operators, equipment vendors, content providers, and other suppliers to the mobile market. Some of the technologies being developed by OMA need XML namespaces that are managed so that they are unique and persistent. To assure that the uniqueness is absolute, the registration of a specific NID for use by OMA was deemed appropriate. Therefore, a full and complete registration will follow the namespace specification process as defined in [RFC3406]. 2. URN Specification for "oma" NID Namespace ID: The NID "oma" is requested. Registration Information: registration version number: 1 registration date: 2005-07-18 Declared registrant of the namespace: Registering organization Name: Open Mobile Alliance Address: 4275 Executive Square Suite 240s La Jolla, CA 92037 Designated contact Role: Technical Program Manager Email: TPM@omaorg.org Declaration of syntactic structure: The Namespace Specific String (NSS) of all URNs that use the "oma" NID will have the following structure: urn:oma:{OMAresource}:{ResourceSpecificString} where the "OMAresource" is a US-ASCII string that conforms to the URN syntax requirements [RFC2141] and defines a specific class of resource type. Each resource type has a specific labeling scheme Smith Informational [Page 2]
RFC 4358 URN Namespace for OMA January 2006 that is covered by "ResourceSpecificString", which also conforms to the naming requirements of [RFC2141]. OMA maintains a naming authority, the Open Mobile Naming Authority (OMNA), that will manage the assignment of "OMAresources" and the specific registration values assigned for each resource class. Relevant ancillary documentation: The Open Mobile Naming Authority (OMNA) provides information on the registered resources and the registrations for each. More information about OMNA and the registration activities and procedures to be followed are available at: http://www.openmobilealliance.org/tech/omna Identifier uniqueness considerations: The OMNA will manage resources using the "oma" NID and will be the authority for managing the resources and subsequent strings associated. In the associated procedures, OMNA will ensure the uniqueness of the strings themselves or shall permit secondary responsibility for management of well-defined sub-trees. OMA may permit use of experimental type values that will not be registered. As a consequence, multiple users may end up using the same value for separate uses. As experimental usage is only intended for testing purposes, this should not be a real issue. Identifier persistence considerations: OMNA will provide clear documentation of the registered uses of the "oma" NID. This will be structured such that each OMAresource will have a separate description and registration table. The registration tables and information will be published and maintained by OMNA on its web site. Process of identifier assignment: OMNA will provide procedures for registration of each type of resource that it maintains. Each such resource may have three types of registration activities: 1) Registered values associated with OMA specs or services 2) Registration of values or sub-trees to other entities 3) Name models for use in experimental purposes Smith Informational [Page 3]
RFC 4358 URN Namespace for OMA January 2006 Process for identifier resolution: The namespace is not listed with an RDS; this is not relevant. Rules for Lexical Equivalence: No special considerations; the rules for lexical equivalence of [RFC2141] apply. Conformance with URN Syntax: No special considerations. Validation mechanism: None specified. URN assignment will be handled by procedures implemented in support of OMNA activities. Scope: Global 3. Examples The following examples are representative urns that could be assigned by OMNA. They may not be the actual strings that would be assigned. urn:oma:ac:oma-presence Defines the urn to be used for the Application Characteristic object definition for providing attributes to the Presence enabler defined in OMA. urn:oma:drms:org-foobar Defines the urn associated with the Digital Rights Management System object definition allocated to foobar, which is an external organization that made request via OMNA for a drms urn. 4. Namespace Considerations The Open Mobile Alliance is developing a variety of application and service enablers. Some of these enablers require that supporting information (e.g., data descriptions, attributes, etc.) be fully specified. For proper operation, descriptions of the needed supporting information must exist and be available in a unique, reliable, and persistent manner. These dependencies provide the basis of need for namespaces, in one form or another. Smith Informational [Page 4]
RFC 4358 URN Namespace for OMA January 2006 As the Open Mobile Alliance work is ongoing and covers many technical areas, the possibility of binding to various other namespace repositories has been deemed impractical. Each object or description, as defined in OMA, could possibly be related to multiple different other namespaces, so further conflicts of association could occur. Thus the intent is to utilize the Open Mobile Naming Authority, operated by OMA, as the naming authority for OMA-defined objects and descriptions. 5. Community Considerations The objects and descriptions required for enablers produced by OMA are generally available for use by other organizations. The Open Mobile Naming Authority will provide access and support for name requests by these organizations. This support can be enabled in a timely and responsive fashion as new objects and descriptions are produced. These will be enabled in a fashion similar to current OMNA support. 6. Security Considerations There are no additional security considerations other than those normally associated with the use and resolution of URNs in general. 7. IANA Considerations The requested NID has been entered into the IANA registry for URN NIDs. The update can be found at: http://www.iana.org/assignments/urn-namespaces and any associated mirrors. 8. Informative References [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. Author's Address Dwight Smith (Chair, Operations and Process Committee, OMA) Motorola 5555 N Beach Street Ft. Worth, TX 76137 EMail: dwight.smith@motorola.com Smith Informational [Page 5]
RFC 4358 URN Namespace for OMA January 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgement Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Smith Informational [Page 6]