1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc4358.txt b/doc/rfc/rfc4358.txt
new file mode 100644
index 0000000..bcfde83
--- /dev/null
+++ b/doc/rfc/rfc4358.txt
@@ -0,0 +1,339 @@
+
+
+
+
+
+
+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]
+