draft-ietf-ecrit-service-urn-policy-02.txt   draft-ietf-ecrit-service-urn-policy-03.txt 
Network Working Group A. Forte Network Working Group A. Forte
Internet-Draft AT&T Internet-Draft AT&T
Intended status: BCP H. Schulzrinne Intended status: BCP H. Schulzrinne
Expires: December 22, 2013 Columbia University Expires: May 30, 2014 Columbia University
June 20, 2013 November 26, 2013
Policy for defining new service-identifying lables Policy for defining new service-identifying labels
draft-ietf-ecrit-service-urn-policy-02.txt draft-ietf-ecrit-service-urn-policy-03.txt
Abstract Abstract
In order to provide location-based services, descriptive terms for In order to provide location-based services, descriptive terms for
services need to be defined. This document updates the policy for services need to be defined. This document updates the policy for
defining new service-identifying labels. defining new service-identifying labels.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
skipping to change at page 1, line 33 skipping to change at page 1, line 33
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on December 22, 2013. This Internet-Draft will expire on May 30, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 14 skipping to change at page 2, line 14
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . . 3
3. Namespace Guidelines . . . . . . . . . . . . . . . . . . . . . 3 3. Namespace Guidelines . . . . . . . . . . . . . . . . . . . . . 3
4. Guidelines for the creation of new top-level services . . . . . 3 4. Guidelines for the creation of new top-level services . . . . . 3
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4
6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 4 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5
1. Introduction 1. Introduction
Nowadays location-based services are widespread. Devices can detect Nowadays location-based services are widespread. Devices can detect
a user location and retrieve all available services in the a user location and retrieve all available services in the
sourroundings of that location. A particular service can be sourroundings of that location. A particular service can be
described by one or multiple terms such as "restaurant", "parking" described by one or multiple terms such as "restaurant", "parking"
and "ATM machine". All such terms, however, need to be formally and "ATM machine". All such terms, however, need to be formally
defined so that a registry can be built and used to assure defined so that a registry can be built and used to assure
consistency and compatibility between devices and between service consistency and compatibility between devices and between service
skipping to change at page 3, line 27 skipping to change at page 3, line 27
new service-identifying labels. new service-identifying labels.
2. Requirements notation 2. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC2119]. document are to be interpreted as described in [RFC2119].
3. Namespace Guidelines 3. Namespace Guidelines
[NOTE: Have we agreed on this approach? Do we allow private [NOTE: Have we agreed on this approach that is, do we allow private
namespaces?] namespaces?]
Whereas one entity applies for the registraton of several new top- Whereas one entity applies for the registraton of several new top-
level services which are of no interest to the general public, the level services which are of no interest to the general public, the
expert reviewer SHOULD consider the creation of an ad-hoc private expert reviewer SHOULD consider the creation of an ad-hoc private
namespace (e.g., urn:nena [citation needed]) under which such entity namespace (e.g., urn:nena [RFC6061]) under which such entity would be
would be free to define its own set of services and service labels. 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 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 the general public or there is just one single top-level service to
be registered, the expert reviewer SHOULD decide for registration in be registered, the expert reviewer SHOULD decide for registration in
the public namespace domain (i.e., urn:service). the public namespace domain (i.e., urn:service).
Namespaces MAY at their discretion use discovery mechanisms other Namespaces MAY, at their discretion, use discovery mechanisms other
than the one described in [RFC5222]. than the one described in [RFC5222].
4. Guidelines for the creation of new top-level services 4. 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?]
The number of services that can be defined is very large. New The number of services that can be defined is very large. New
services, however, SHOULD at least satisfy the following guidelines. services, however, SHOULD at least satisfy the following guidelines.
- The service MUST NOT overlap with any other service previously - The service MUST NOT overlap with any other service previously
registered; registered;
- The service has to be of general interest; - The service has to be of general interest;
- It should not be specific to a particular country or region; - It should not be specific to a particular country or region;
skipping to change at page 4, line 21 skipping to change at page 4, line 25
(this is a protocol token, not meant to be shown to humans); (this is a protocol token, not meant to be shown to humans);
- The newly defined services SHOULD correspond to a standard - The newly defined services SHOULD correspond to a standard
statistical classification of enterprises or services, such as the statistical classification of enterprises or services, such as the
North American Industry Classification System (NAICS). North American Industry Classification System (NAICS).
5. IANA Considerations 5. IANA Considerations
This document updates Section 4.1 of [RFC5031] in that the policy for This document updates Section 4.1 of [RFC5031] in that the policy for
adding top-level service labels is "Expert Review". The expert is adding top-level service labels is "Expert Review". The expert is
designated by the RAI Area Director. [NOTE: Add requirement for designated by the RAI Area Director.
external non-IETF document or template here?]
[NOTE: Add requirement for external non-IETF document or template
here?]
6. Security Considerations 6. Security Considerations
This document does not raise security issues. This document does not raise security issues.
7. References 7. References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for [RFC5031] Schulzrinne, H., "A Uniform Resource Name (URN) for
Emergency and Other Well-Known Services", RFC 5031, Emergency and Other Well-Known Services", RFC 5031,
January 2008. January 2008.
[RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H. [RFC5222] Hardie, T., Newton, A., Schulzrinne, H., and H.
Tschofenig, "LoST: A Location-to-Service Translation Tschofenig, "LoST: A Location-to-Service Translation
Protocol", RFC 5222, August 2008. Protocol", RFC 5222, August 2008.
[RFC6061] Rosen, B., "Uniform Resource Name (URN) Namespace for the
National Emergency Number Association (NENA)", RFC 6061,
January 2011.
Authors' Addresses Authors' Addresses
Andrea G. Forte Andrea G. Forte
AT&T AT&T
Security Research Center Security Research Center
33 Thomas Street 33 Thomas Street
New York, NY 10007 New York, NY 10007
USA USA
Email: forte@att.com Email: forte@att.com
 End of changes. 10 change blocks. 
12 lines changed or deleted 21 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/