summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6061.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6061.txt')
-rw-r--r--doc/rfc/rfc6061.txt395
1 files changed, 395 insertions, 0 deletions
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:<responder name>"
+ 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]
+