Network Working Group A. Forte Internet-Draft AT&T Intended status: BCP H. Schulzrinne Expires: December 22, 2013 Columbia University June 20, 2013 Policy for defining new service-identifying lables draft-ietf-ecrit-service-urn-policy-02.txt Abstract In order to provide location-based services, descriptive terms for services need to be defined. This document updates the policy for defining new service-identifying labels. 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 December 22, 2013. Copyright Notice Copyright (c) 2013 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. Forte & Schulzrinne Expires December 22, 2013 [Page 1] Internet-Draft Service URN Policy June 2013 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 3. Namespace Guidelines . . . . . . . . . . . . . . . . . . . . . 3 4. Guidelines for the creation of new top-level services . . . . . 3 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 Forte & Schulzrinne Expires December 22, 2013 [Page 2] Internet-Draft Service URN Policy June 2013 1. Introduction Nowadays location-based services are widespread. Devices can detect a user location and retrieve all available services in the sourroundings of that location. A particular service can be described by one or multiple terms such as "restaurant", "parking" and "ATM machine". All such terms, however, need to be formally defined so that a registry can be built and used to assure consistency and compatibility between devices and between service providers. Since descriptive terms for services are almost unbounded, such registry would contain the most common terms. In this document we update the policy for defining new terms, that is new service-identifying labels. 2. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 3. Namespace Guidelines [NOTE: Have we agreed on this approach? Do we allow private namespaces?] Whereas one entity applies for the registraton of several new top- level services which are of no interest to the general public, the expert reviewer SHOULD consider the creation of an ad-hoc private namespace (e.g., urn:nena [citation needed]) under which such entity would be free to define its own set of services and service labels. On the other hand, if the new top-level services are of interest to the general public or there is just one single top-level service to be registered, the expert reviewer SHOULD decide for registration in the public namespace domain (i.e., urn:service). Namespaces MAY at their discretion use discovery mechanisms other than the one described in [RFC5222]. 4. Guidelines for the creation of new top-level services The number of services that can be defined is very large. New services, however, SHOULD at least satisfy the following guidelines. - The service MUST NOT overlap with any other service previously Forte & Schulzrinne Expires December 22, 2013 [Page 3] Internet-Draft Service URN Policy June 2013 registered; - The service has to be of general interest; - It should not be specific to a particular country or region; - The language in which the new service is defined MUST be English (this is a protocol token, not meant to be shown to humans); - The newly defined services SHOULD correspond to a standard statistical classification of enterprises or services, such as the North American Industry Classification System (NAICS). 5. IANA Considerations This document updates Section 4.1 of [RFC5031] in that the policy for adding top-level service labels is "Expert Review". The expert is designated by the RAI Area Director. [NOTE: Add requirement for external non-IETF document or template here?] 6. Security Considerations This document does not raise security issues. 7. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for Emergency and Other Well-Known Services", RFC 5031, January 2008. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008. Forte & Schulzrinne Expires December 22, 2013 [Page 4] Internet-Draft Service URN Policy June 2013 Authors' Addresses Andrea G. Forte AT&T Security Research Center 33 Thomas Street New York, NY 10007 USA Email: forte@att.com Henning Schulzrinne Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: hgs@cs.columbia.edu Forte & Schulzrinne Expires December 22, 2013 [Page 5]