From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6061.txt | 395 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 395 insertions(+) create mode 100644 doc/rfc/rfc6061.txt (limited to 'doc/rfc/rfc6061.txt') diff --git a/doc/rfc/rfc6061.txt b/doc/rfc/rfc6061.txt new file mode 100644 index 0000000..9d8be35 --- /dev/null +++ b/doc/rfc/rfc6061.txt @@ -0,0 +1,395 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Rosen +Request for Comments: 6061 NeuStar +Category: Informational January 2011 +ISSN: 2070-1721 + + +Uniform Resource Name (URN) Namespace for the National Emergency Number + Association (NENA) + +Abstract + + This document describes the Namespace Identifier (NID) "nena" for + Uniform Resource Name (URN) resources published by the National + Emergency Number Association (NENA). NENA defines and manages + resources that utilize this URN model. Management activities for + these and other resource types are provided by the NENA Registry + System (NRS). + +Status of This Memo + + This document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6061. + +Copyright Notice + + Copyright (c) 2011 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 + (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 Simplified BSD License. + + + +Rosen Informational [Page 1] + +RFC 6061 URN nena Namespace January 2011 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. URN Specification for "nena" NID ................................2 + 3. Examples ........................................................4 + 4. Namespace Considerations ........................................5 + 5. Community Considerations ........................................5 + 6. Security Considerations .........................................6 + 7. IANA Considerations .............................................6 + 8. Acknowledgements ................................................6 + 9. References ......................................................7 + 9.1. Normative References .......................................7 + 9.2. Informative References .....................................7 + +1. Introduction + + The National Emergency Number Association (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. Some of the solutions being + developed by NENA require 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 is required. This + document defines and registers such a namespace in accordance with + [RFC3406]. + +2. URN Specification for "nena" NID + + Namespace ID: nena + + Registration information: + + registration version number: 1 + + registration date: 2010-10-13 + + 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 + + + +Rosen Informational [Page 2] + +RFC 6061 URN nena Namespace January 2011 + + + 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" 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) Registry 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 Registry System (NRS) + provides information on the registered resources and the + registrations for each. More information about the NRS and the + registration activities and procedures to be followed are defined + in "NENA Registry System Standard", NENA 70-001 [NENA70-001], + which is available at http://www.nena.org/. + + Identifier uniqueness considerations: + + The NRS will manage resources using the "nena" NID and will be the + authority for managing the resources and subsequent strings + associated. The NRS shall ensure the uniqueness of all nena URNs + by checking such names against the list of existing namespace + names, as documented in NENA 70-001 [NENA70-001]. + + Identifier persistence considerations: + + The NRS will provide clear documentation of the registered uses of + the "nena" NID. The NRS will establish a registry for + "NENAclass", as defined in NENA08-003 [NENA08-003]. Each + "NENAclass" will have a separate description in the registry and + may have its own sub-registry. In particular, new "NENAclass" + registry entries will require a full NENA Technical Standard + document. + + The NRS will maintain a website at a stable address that provides XML + and text renderings of the urn:nena registry. + + + + + +Rosen Informational [Page 3] + +RFC 6061 URN nena Namespace January 2011 + + + Process of identifier assignment: + + The NRS processes and procedures for identifier assignment are + documented in NENA 07-001 [NENA70-001]. The registry that will + control the urn:nena namespace is defined in NENA 08-003 + [NENA08-003]. In particular, assignments to the "NENAclass" + registry will require a NENA Technical Standard document. + Subregistries for particular "NENAclasses" may be established by + such technical standards. Subregistries may be defined to have + more liberal management policies as defined in NENA 70-001 + [NENA70-001], but must be NRS managed and will not be permitted to + be delegated to any other organization or registry. Thus, the NRS + will manage the entire urn:nena tree. + + Process for identifier resolution: + + The namespace is not currently listed with a Resolution Discovery + System (RDS), but nothing about the namespace prohibits the future + definition of appropriate resolution methods or listing with + an RDS. + + 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 the NRS. They may not be the actual strings that would be + assigned. + + + + + + + +Rosen Informational [Page 4] + +RFC 6061 URN nena Namespace January 2011 + + + NENAresource "psaproute" + Syntax: "urn:nena:emergencyresponders:" + ResourceSpecificString: simple string with name of responder, + defined in a subregistry + 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:nena: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 has developed standards for + emergency calling in North America for several decades. NENA is + developing a variety of applications and services using Internet + protocols built upon IETF standards. 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 the need for namespaces, in one form or another, and + will enable NENA to define URNs that are to assign cleaner, more + general, more permanent, more reliable, and more controllable + namespace names related to NENA standards, while keeping URNs defined + by NENA properly separate from the IETF-defined URNs. + + 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 namespaces, so further conflicts of association + could occur. Thus, the intent is to utilize the National Emergency + Number Association Registry System, operated by NENA, as the naming + authority for NENA-defined objects and descriptions. + +5. Community Considerations + + The North American public safety organizations will benefit from + publication of this namespace by having permanent and reliable URNs + to be used with protocols defined by NENA. The objects and + descriptions required for services defined by NENA are generally + available for use by other organizations. The National Emergency + + + +Rosen Informational [Page 5] + +RFC 6061 URN nena Namespace January 2011 + + + Number Association will provide access and support for name requests + by these organizations within the constraints of the defined NRS + processes and the specific urn:nena registry and subregistries. 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, as documented in + NENA70-001 [NENA70-001]. + + The NRS establishes registries when called for in a NENA Technical + Standard. Such standards must provide the NRS with clear and concise + instructions on creating and maintaining such registries. Defined + management policies include "NENA Technical Standard Required", "NENA + Document Required", "Expert Review", and "First Come First Served", + which correspond to similar IANA management policies. NENA is + establishing a website that provides controlled entry of new + registries and entries in registries, and automatically produces HTML + and XML descriptions of registry contents that are used by vendors + and other consumers of the content. + +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 is "nena". The defining document is this RFC. The entry + can be found in the Uniform Resource Names (URN) Namespaces registry + available from http://www.iana.org 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. + + + + + + + + + + + + + + + +Rosen Informational [Page 6] + +RFC 6061 URN nena Namespace January 2011 + + +9. References + +9.1. Normative References + + [RFC2141] Moats, R., "URN Syntax", RFC 2141, May 1997. + +9.2. Informative References + + [NENA08-003] NENA, "Detailed Functional and Interface Specification + for the NENA i3 Solution - Stage 3", NENA Standard + 08-003, September 2010. + + [NENA70-001] NENA, "NENA Registry System Standard", NENA + Standard 70-001, September 2009. + + [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 Informational [Page 7] + -- cgit v1.2.3