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 2013Table 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 20131. 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 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
datatracker.ietf.org