doc: Add RFC documents

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