Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


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)


 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

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

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

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

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

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.

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

Rosen Informational [Page 7]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6061.txt · Last modified: 2011/01/06 18:41 by

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki