From: http://www.ietf.org/id/draft-rosen-urn-nena-01.txt Title: URN Namespace for National Emergency Number Association (NENA) Reference: IETF Network Working Group, Internet Draft 'draft-rosen-urn-nena-01' Date: January 19, 2010 I-D Tracker: http://ietfreport.isoc.org/idref/draft-rosen-urn-nena/ Tools: http://tools.ietf.org/html/draft-rosen-urn-nena-01 (HTML) Diff with version -00: http://tools.ietf.org/rfcdiff?url2=draft-rosen-urn-nena-01.txt Announced: http://www.ietf.org/mail-archive/web/ietf-announce/current/msg06996.html Status 2010-02-04: Last Call The Internet Engineering Steering Group (IESG) has received a request to consider the document "URN Namespace for National Emergency Number Association (NENA)" 'draft-rosen-urn-nena-01.txt' as an Informational RFC. The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the IETF by 2010-03-04. ============================================================================== Network Working Group B. Rosen Internet-Draft NeuStar Intended status: Informational January 19, 2010 Expires: July 23, 2010 URN Namespace for National Emergency Number Association (NENA) draft-rosen-urn-nena-01 Abstract This document describes the Namespace Identifier (NID) 'nena' for Uniform Resource Names (URN) resources published by National Emergency Number Association (NENA). NENA defines and manages resources that utilize this URN name model. Management activities for these and other resource types are provided by the National Emergency Number Association (NENA) Registry System (NRS). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on July 23, 2010. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Rosen Expires July 23, 2010 [Page 1] Internet-Draft URN nena Namespace January 2010 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. URN Specification for "nena" NID . . . . . . . . . . . . . . . 4 3. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4. Namespace Considerations . . . . . . . . . . . . . . . . . . . 6 5. Community Considerations . . . . . . . . . . . . . . . . . . . 6 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . . 7 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 7 Rosen Expires July 23, 2010 [Page 2] Internet-Draft URN nena Namespace January 2010 1. Introduction NENA is the "Voice of 9-1-1" in North America. NENA's mission is to foster the technological advancement, availability and implementation of a universal emergency telephone number system (9-1-1). In carrying out its mission, NENA promotes research, planning, training and education. The protection of human life, the preservation of property, and the maintenance of general community security are among NENA's objectives. NENA serves as a link in the delivery of emergency services. 9-1-1 has, throughout its evolution, become recognized as an asset of the North American public. NENA is currently in the process of setting standards, processes and procedures for the use of an IP-based Emergency Services IP Network (ESInet) for all public safety entities in North America. This activity is supported by a membership composed of private and public sector entities that have an interest in 9-1-1 and public safety. This effort, dubbed "Next Generation 9-1-1" (NG9-1-1) is based in large part on IETF standards for interactive media session establishment and emergency calling. Some of the solutions being developed by NENA 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 Uniform Resource Name (URN) [RFC2141] Namespace ID (NID) for use by NENA was deemed appropriate. Therefore, a full and complete registration will follow the namespace specification process as defined in [RFC3406]. Rosen Expires July 23, 2010 [Page 3] Internet-Draft URN nena Namespace January 2010 2. URN Specification for "nena" NID Namespace ID: nena Registration Information: registration version number: 1 registration date: YYYY-MM-DD [RFC Editor, please replace with the date of approval of this document for publication as an RFC] Declared registrant of the namespace: Registering organization Name: National Emergency Number Association (NENA) Address: 4350 North Fairfax Drive, Suite 750 Arlington, VA 22203-1695 Designated contact: Role: NENA Registry Services Administrator Email: nrs-admin@nena.org Declaration of syntactic structure: The Namespace Specific String (NSS) of all URNs that use the "nena" NID will have the following structure: {NENAclass}:ClassSpecificString} The "NENAclass" is a US-ASCII string that conforms to the URN syntax requirements [RFC2141] and defines a specific class of resource type. Each class will have a specific labeling scheme that is covered by "ClassSpecificString", which also conforms to the naming requirements of [RFC2141]. NENA maintains a naming authority, the National Emergency Number Association (NENA) Registration System (NRS) that will manage the assignment of "NENAclass" and the specific registration values assigned for each class. Other NENA Standards documents will define the "ClassSpecificStrings" for a given "NENAclass". Relevant ancillary documentation: The National Emergency Number Association Registration System (NRS) provides information on the registered resources and the registrations for each. More information about NRS and the registration activities and procedures to be followed are defined in "Managing Registries for NENA Next Generation Data Elements Technical Standard Document", NENA 70-001, which is available at: http://www.nena.org/standard/nena-registry-system. Identifier uniqueness considerations: The NRS will manage resources using the "nena" NID and will be the authority for managing the resources and subsequent strings Rosen Expires July 23, 2010 [Page 4] Internet-Draft URN nena Namespace January 2010 associated. In the associated procedures, NRS will ensure the uniqueness of the strings themselves or shall permit secondary responsibility for management of well-defined sub-trees. NENA 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: NRS will provide clear documentation of the registered uses of the "nena" NID. NRS will establish a registry for NENAclass. Each NENAclass will have a separate description in the registry and may have its own sub-registry. The registries and information will be published and maintained by NRS on its web site. Process of identifier assignment: NRS will provide procedures for registration of each class that it maintains. Each such resource may have three types of registration activities: 1. Registered values associated with NENA specifications or services 2. Registration of values or sub-registries 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 NENA activities. Scope: Global 3. Examples The following examples are representative urns that could be assigned by NRS. They may not be the actual strings that would be assigned. Rosen Expires July 23, 2010 [Page 5] Internet-Draft URN nena Namespace January 2010 NENAresource "psaproute" Syntax: "urn:nena.emergencyresponders:" ResourceSpecificString: simple string with name of responder, defined in a sub-registry Use: Defines the urn to be used for queries to an NG9-1-1 Emergency Call Routing Function that provides URIs for responding agencies. Examples: urn:nena:emergencyresponders:ambulance urn:neon:emergencyresponders:fire urn:nena:emergencyresponders:police urn:nena:emergencyresponders:poison urn:nena:emergencyresponders:coastguard urn:nena:emergencyresponders:marine 4. Namespace Considerations The National Emergency Number Association is developing a variety of applications and services. Some of these services 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 National Emergency Number Association 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 NENA, could possibly be related to multiple different other namespaces, so further conflicts of association could occur. Thus the intent is to utilize the National Emergency Number Association Registration System, operated by NENA, as the naming authority for NENA-defined objects and descriptions. 5. Community Considerations The objects and descriptions required for services defined by NENA are generally available for use by other organizations. The National Emergency Number Association 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 IANA processes. Rosen Expires July 23, 2010 [Page 6] Internet-Draft URN nena Namespace January 2010 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 This document adds a new entry in the urn-namespaces registry. The namespace should be "nena". The defining document is this RFC. The entry can be found at: http://www.iana.org/assignments/urn-namespaces and any associated mirrors. 8. Acknowledgements The author thanks Alfred Hoenes (TR-Sys) for his careful reading and extensive comments and suggestions. The author also acknowledges that the text from [RFC4358] formed the basis of this document. 9. References 9.1. Normative References [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. 9.2. Informative References [RFC3406] Daigle, L., van Gulik, D., Iannella, R., and P. Faltstrom, "Uniform Resource Names (URN) Namespace Definition Mechanisms", BCP 66, RFC 3406, October 2002. [RFC4358] Smith, D., "A Uniform Resource Name (URN) Namespace for the Open Mobile Alliance (OMA)", RFC 4358, January 2006. Author's Address Brian Rosen NeuStar, Inc. 470 Conrad Dr Mars, PA 16046 US Email: br@brianrosen.net Rosen Expires July 23, 2010 [Page 7]