Network Working Group                                           A. Forte
Internet-Draft                                                      AT&T
Intended status: BCP                                      H. Schulzrinne
Expires: May 30, 2014                                Columbia University
                                                       November 26, 2013


           Policy for defining new service-identifying labels
               draft-ietf-ecrit-service-urn-policy-03.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 May 30, 2014.

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 May 30, 2014                  [Page 1]

Internet-Draft             Service URN Policy              November 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  . . . . . . . . . . . . . . . . . . . . . . . . 5









































Forte & Schulzrinne       Expires May 30, 2014                  [Page 2]

Internet-Draft             Service URN Policy              November 2013


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


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


.  Namespace Guidelines

   [NOTE: Have we agreed on this approach that is, 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 [RFC6061]) 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].


.  Guidelines for the creation of new top-level services

   [NOTE: Should this section apply only to the public namespace domain?
   Do we want to give some general guidelines for private namespaces as
   well?]




Forte & Schulzrinne       Expires May 30, 2014                  [Page 3]

Internet-Draft             Service URN Policy              November 2013


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


.  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?]


.  Security Considerations

   This document does not raise security issues.


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

   [RFC6061]  Rosen, B., "Uniform Resource Name (URN) Namespace for the
              National Emergency Number Association (NENA)", RFC 6061,



Forte & Schulzrinne       Expires May 30, 2014                  [Page 4]

Internet-Draft             Service URN Policy              November 2013


              January 2011.


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 May 30, 2014                  [Page 5]