Uniform Resource Name (URN) Namespace for the European Emergency Services
draft-lumbreras-ees-urn-00.txt

Abstract

This document describes the Namespace Identifier (NID) "eena" for Uniform Resource Name (URN) resources published by the European Emergency Number Association (EENA). EENA defines and manages resources that utilize this URN model. Management activities for these and other resource types are provided by the European Emergency Services Registry (EESR).

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http:/⁠/⁠datatracker.ietf.org/⁠drafts/⁠current/⁠.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on April 16, 2013.

Copyright Notice

Copyright (c) 2012 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.

Table of Contents

• 1. Introduction
• 2. URN Specification for 'ees' NID
• 3. Examples
• 4. Namespace Considerations
• 5. Community Considerations
• 6. Security Considerations
• 7. IANA Considerations
• 8. Acknowledgements
• 9. References
• 9.1. Normative References
• 9.2. Informative References
• Authors' Addresses

1. Introduction

The European Emergency Number Association (EENA) 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 Europe. Some of the solutions being developed by EENA require 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 EENA is required. This document defines and registers such a namespace in accordance with the procedures in [RFC3406].

2. URN Specification for 'ees' NID

• Namespace ID: ees
• Registration information:
  
  
  • Registration version number: 1
  • Registration date: 2012-09-26

• Declared registrant of the namespace:
  
  
  • Registering organization
  • Name: European Emergency Number Association (EENA)
  • Address:
    
    
    • Avenue de la Toison d'Or 79,
    • 1060 Brussels
    • Belgium

• Designated contact:
  
  
  • Role: European Emergency Services Registry Administrator
  • Email: eesr-admin@eena.org

• Declaration of syntactic structure:
  
  The Namespace Specific String (NSS) of all URNs that use the "eena" NID will have the following structure: {EESclass}:{ClassSpecificString}
  
  The "EESclass" 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].
  
  EENA maintains a naming authority, the European Emergency Service Registry (EESR), that will manage the assignment of "EESclass" and the specific registration values assigned for each class. Other EENA standards documents will define the "ClassSpecificStrings" for a given "EESclass".
• Relevant ancillary documentation:
  
  The European Emergency Service Registry (EESR) provides information on the registered resources and the registrations for each. More information about the EESR and the registration activities and procedures to be followed are defined in the "EENA Registry System Standard" [EENA-RSS].
• Identifier uniqueness considerations:
  
  The EESR will manage resources using the "ees" NID and will be the authority for managing the resources and subsequent strings associated. The EESR shall ensure the uniqueness of all ees URNs by checking such names against the list of existing namespace names, as documented in [EENA-RSS].
• Identifier persistence considerations:
  
  The EESR will provide clear documentation of the registered uses of the "ees" NID. The EESR will establish a registry for "EESclass", as defined in [EENA-RSS]. Each "EESclass" will have a separate description in the registry and may have its own sub-registry. In particular, new "EESclass" registry entries will require a full EENA Technical Standard document.
  
  The EESR will maintain a website at a stable address that provides XML and text renderings of the urn:ees registry.
• Process of identifier assignment:
  
  The EESR processes and procedures for identifier assignment are documented in [EENA-RSS]. The registry that will control the urn:ees namespace is defined in [EENA-RSS]. In particular, assignments to the "EESclass" registry will require a EENA Technical Standard document. Subregistries for particular "EENAclasses" may be established by such technical standards. Subregistries may be defined to have more liberal management policies as defined in [EENA-RSS], but must be EESR managed and will not be permitted to be delegated to any other organization or registry. Thus, the EESR will manage the entire urn:ees 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 EENA activities.
• Scope:
  
  Global

3. Examples

The following examples are representative URNs that could be assigned by the ERS. They may not be the actual strings that would be assigned.

Resource "psaproute"

Syntax: "urn:ees: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 NG112 Emergency Call Routing Function that provides URIs for responding agencies.

Examples:

urn:ees:emergencyresponders:ambulance

urn:ees:emergencyresponders:fire

urn:ees:emergencyresponders:police

urn:ees:emergencyresponders:poison

urn:ees:emergencyresponders:coastguard

urn:ees:emergencyresponders:marine

4. Namespace Considerations

The European Emergency Number Association is a Brussels-based NGO set up in 1999 dedicated to promoting high-quality emergency services reached by the number 112 throughout the EU. EENA serves as a discussion platform for emergency services, public authorities, decision makers, associations and solution providers in view of improving emergency response in accordance with citizens' requirements. EENA is also promoting the establishment of an efficient system for alerting citizens about imminent or developing emergencies.

The EENA memberships include about 655 emergency services representatives from 43 European countries, 56 solution providers, 9 international associations/organisations as well as 26 Members of the European Parliament.

EENA members do their work in committees, which also includes a technical committee that develops 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 EENA to define URNs that are to assign cleaner, more general, more permanent, more reliable, and more controllable namespace names related to EENA standards, while keeping URNs defined by EENA properly separate from the IETF-defined URNs.

As the European 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 EENA, could possibly be related to multiple different namespaces, so further conflicts of association could occur. Thus, the intent is to utilize the European Emergency Services Registry, operated by EENA, as the naming authority for EENA-defined objects and descriptions.

5. Community Considerations

The European public safety organizations will benefit from publication of this namespace by having permanent and reliable URNs to be used with protocols defined by EENA. The objects and descriptions required for services defined by EENA are generally available for use by other organizations. The European Emergency Number Association will provide access and support for name requests by these organizations within the constraints of the defined ERS processes and the specific urn:eena 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 [EENA-RSS].

The EESR establishes registries when called for in a EENA Technical Standard. Such standards must provide clear and concise instructions on creating and maintaining such registries. Defined management policies include "EENA Technical Standard Required", "EENA Document Required", "Expert Review", and "First Come First Served", which correspond to similar IANA management policies. EENA 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 "eena". 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

We would like to thank Brian Rosen for his work on RFC 6061. We have re-used his writeup since it aims to accomplish the same goal. His work was focused on the National Emergency Number Association, a partner organization of EENA.

9. References

9.1. Normative References

9.2. Informative References

Authors' Addresses