RFC 4358 INFORMATIONAL URN · MOBILE · NAMING

A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)

A namespace for the Open Mobile Alliance to uniquely name mobile specifications and resources.

On rfc-editor.org ↗
PUBLISHED
January 2006
AUTHORS
D. Smith
STREAM
IETF
NAMESPACE IDENTIFIER
oma
REGISTRATION DATE
2005-07-18
MANAGING AUTHORITY
Open Mobile Naming Authority (OMNA)
REGISTRATION TYPES
3 (OMA specs, delegated to others, experimental)
DOI
10.17487/RFC4358

RFC text

Contents
Original text · RFC Editor View on rfc-editor.org ↗
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

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
      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

   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.

   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

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).

AI ELI5

On this page
PROBLEMThe Open Mobile Alliance develops technologies for mobile devices and needs unique, persistent identifiers for the XML descriptions, schemas, and objects those technologies define.
MECHANISMThe RFC registers the URN namespace identifier 'oma', which follows the pattern 'urn:oma:{OMAresource}:{ResourceSpecificString}', managed by the Open Mobile Naming Authority (OMNA).
MOBILE SPECIFICATION NAMESOMA-defined objects and specifications can be uniquely identified and referenced, with room for experimental values and delegation to external organizations.

§1OMA and the Need for Persistent Names

The Open Mobile Alliance (OMA) is a standards development body that defines technologies for mobile devices. Its membership includes network operators, equipment vendors, content providers, and other suppliers to the mobile market.

As OMA develops 'enablers' (application and service specifications), they need to specify supporting information such as data descriptions, attributes, XML schemas, and object definitions. This information must exist and be available in a unique, reliable, and persistent manner, independent of where it is stored on the internet.

Because OMA's work spans many technical areas and an object could relate to multiple different other namespaces, using a dedicated URN namespace for OMA-defined resources is more practical than binding to multiple external registries. The RFC registers the namespace identifier 'oma' for this purpose.

Mobile phone companies create standards for how devices should work. To name all the descriptions and rules they create, they needed their own identifier system that stays the same no matter where the files are stored.

§2The URN Specification

OMA URNs follow this structure:

urn:oma:{OMAresource}:{ResourceSpecificString}

The OMAresource is a US-ASCII string that defines a specific class or type of resource. Examples include 'ac' for Application Characteristic or 'drms' for Digital Rights Management System. Each resource type has its own labeling scheme defined by the ResourceSpecificString, which can also use US-ASCII characters conforming to URN syntax.

The Open Mobile Naming Authority (OMNA) manages the assignment of OMAresource values and the registration of specific strings for each resource class.

Examples of valid OMA URNs include:

  • urn:oma:ac:oma-presence (Application Characteristic for presence)
  • urn:oma:drms:org-foobar (Digital Rights Management System for external organization 'foobar')

Each name has three parts after 'oma': a category (like 'drms' for Digital Rights), a specific type (like 'org-something'), and identifiers that follow strict rules so names never collide.

§3Authority and Registration Process

The Open Mobile Naming Authority (OMNA) is responsible for managing OMA URNs. OMNA ensures uniqueness of the strings and provides clear documentation of registered uses. The organization publishes registration information on its web site at http://www.openmobilealliance.org/tech/omna.

OMNA manages three types of registration activities:

  • Registered values for OMA specifications and services
  • Registration of values or sub-trees delegated to other external entities
  • Experimental name models for testing purposes (not formally registered)

OMA permits experimental values that are not registered. As a result, multiple users may use the same experimental value for different testing purposes. Since experimental usage is only intended for testing, this is acceptable.

Unique identifiers are ensured by OMNA procedures that prevent duplication, whether the registration is for OMA itself or delegated to external organizations requesting URNs from OMNA.

One authority (OMNA) manages all the names and keeps a public list of what each one means. They allow special experimental names for testing, as long as they are not mixed up with the permanent, official ones.

§4Persistence and Scope

OMNA maintains registration tables and information in published documentation that covers each OMAresource class separately, with its own description and registration table. This ensures that registered URNs remain persistent and resolvable over time.

The scope of the OMA namespace is global, meaning OMA URNs are valid and resolvable anywhere on the internet. This reflects OMA's international role in mobile standards.

Because OMNA is structured as a separate, long-term authority within OMA, the namespace is expected to persist as long as OMA exists. The registration model is designed so that once a URN is assigned, it is not reassigned to a different resource, ensuring that over time, OMA URNs maintain their value as persistent identifiers.

Once OMA names something with a URN, that name means the same thing forever. OMA keeps the official list on the internet so anyone can look up what an OMA URN means, anywhere in the world.

§5References