One document matched: draft-rosen-urn-nena-03.xml

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2141 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2141.xml">
<!ENTITY rfc3406 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3406.xml">
<!ENTITY rfc4358 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4358.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="yes" ?>
<?rfc compact="yes"?>
<rfc category="info" ipr="trust200902">
  <front>
    <title abbrev='URN nena Namespace'>
      Universal Resource Name (URN) Namespace for National Emergency Number Association (NENA)
    </title>

    <author fullname="Brian Rosen" initials="B.R." surname="Rosen">
      <organization abbrev="NeuStar">NeuStar, Inc.</organization>

      <address>
        <postal>
          <street>470 Conrad Dr</street>

          <city>Mars</city>

          <region>PA</region>

          <code>16046</code>

          <country>US</country>
        </postal>

        <email>br@brianrosen.net</email>
      </address>
    </author>

    <date year="2010" />

    <area>app</area>

<abstract>
<t>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 model.  Management activities for these and other resource types are provided by the NENA Registry System (NRS).  </t>
</abstract></front><middle>
<section title="Introduction">	
<t>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) <xref target="RFC2141"/> Namespace ID (NID) for use by NENA is required. This document defines and registers such a namespace.</t>
</section>
<section title='URN Specification for "nena" NID'>
<figure><artwork>
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}
</artwork></figure><t>
The "NENAclass" conforms to the URN
syntax requirements <xref target="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 <xref target="RFC2141"/>.
</t><t>
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".
</t><t>
Relevant ancillary documentation:<vspace/>
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 "NENA Registry System Standard", 
<xref target="NENA70-001">NENA 70-001</xref>, which is available at: 
http://www.nena.org/standard/nena-registry-system. 
</t><t>
Identifier uniqueness considerations:<vspace/>
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 <xref target="NENA70-001">NENA 70-001</xref>.
</t><t>
Identifier persistence considerations:<vspace/>
NRS will provide clear documentation of the registered uses of the 
"nena" NID.  NRS will establish a registry for NENAclass as defined in <xref target="NENA08-003">NENA08-003</xref>. 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.  
</t><t>
NRS will maintain a website at a stable address which provides XML and text renderings of the urn:nena registry.
</t><t>
Process of identifier assignment:<vspace/>
The NRS processes and procedures for identifier assignment is documented in <xref target="NENA70-001">NENA 07-001</xref>.  The registry that will control the urn:nena namespace is defined in <xref target="NENA08-003">NENA 08-003</xref>.  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 <xref target="NENA70-001">NENA 70-001</xref>, but must be NRS managed and will not be permitted to be delegated to any other organization or registry.  Thus NRS will manage the entire urn:nena tree.
</t><t>
Process for identifier resolution:<vspace/> 
   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.
</t><t>
Rules for Lexical Equivalence:<vspace/>
No special considerations; the rules for lexical equivalence of
<xref target="RFC2141"/> apply.
</t><t>
Conformance with URN Syntax:<vspace/>
	No special considerations.
</t><t>
Validation mechanism:<vspace/>
None specified.  URN assignment will be handled by procedures 
implemented in support of NENA activities.
</t><t>
Scope:<vspace/>
	Global
</t>
</section>
<section title="Examples">
<t>The following examples are representative URNs that could be
assigned by NRS.  They may not be the actual strings that would be assigned.</t>

<figure><artwork>
NENAresource "psaproute"
Syntax: "urn:nena:emergencyresponders:<responder name>"
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:nena:emergencyresponders:fire
urn:nena:emergencyresponders:police
urn:nena:emergencyresponders:poison
urn:nena:emergencyresponders:coastguard
urn:nena:emergencyresponders:marine
</artwork></figure></section>
<section title="Namespace Considerations">
<t>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 on 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 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.
</t><t>
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.</t>
</section>
<section title="Community Considerations">
<t>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 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 <xref target="NENA70-001">NENA70-001</xref>.</t>
<t>NRS establishes registries when called for in a NENA Technical Standard.  Such standards must provide 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 which 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.</t>   
</section>
<section title="Security Considerations">
<t>There are no additional security considerations other than those normally associated with the use and resolution of URNs 
in general.</t>
</section>
<section title="IANA Considerations">
<t>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.</t>
</section>
<section title="Acknowledgements">
<t>The author thanks Alfred Hoenes (TR-Sys) for his careful reading and extensive comments and
   suggestions.  The author also acknowledges that the text from <xref target="RFC4358"/> formed the basis of this
   document.
</t></section>

  </middle>

  <back>
    <references title="Normative References">
      &rfc2141;
    </references>
    <references title="Informative References">
      &rfc3406;
      &rfc4358;
      <reference anchor="NENA70-001">
        <front>
          <title abbrev="NENA70-001">NENA Registry System Standard</title>
          <author>
            <organization>NENA</organization>
          </author>
          <date month="September" year="2009"/>
        </front>
        <seriesInfo name="NENA Standard"
                    value="70-001"/>
      </reference>
      <reference anchor="NENA08-003">
        <front>
          <title abbrev="NENA08-003">Detailed Functional and Interface Specification for the NENA i3 Solution – Stage 3</title>
          <author>
            <organization>NENA</organization>
          </author>
          <date month="September" year="2010"/>
        </front>
        <seriesInfo name="NENA Standard"
                    value="08-003"/>
      </reference>

    </references>
  </back>
</rfc>