Network Working Group A. Forte Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia University Expires: September 24, 2009 March 23, 2009 Labels for Common Location-Based Services draft-forte-ecrit-service-classification-02.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. 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." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on September 24, 2009. Copyright Notice Copyright (c) 2009 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 in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This document creates a registry for describing the types of services available at a specific location. The registry is then referenced by other protocols that need a common set of service terms as protocol Forte & Schulzrinne Expires September 24, 2009 [Page 1] Internet-Draft Service Classification March 2009 constants. In particular, we define location-based service as either a point at a specific geographic location (e.g., bus stop) or a service covering a specific region (e.g., pizza delivery). Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Location-based services . . . . . . . . . . . . . . . . . . . 3 4. Guidelines for the creation of new top-level services . . . . 8 5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 6.1. Registering tokens . . . . . . . . . . . . . . . . . . . . 8 6.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-service . . . . . . . . . 9 6.3. Schema Registration for Schema urn:ietf:params:xml:ns:location-service . . . . . . . . . 9 7. Internationalization Considerations . . . . . . . . . . . . . 9 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Forte & Schulzrinne Expires September 24, 2009 [Page 2] Internet-Draft Service Classification March 2009 1. Introduction We anticipate that the network, through configuration or management protocols, tells a mobile device what kind of location it finds itself in and what kind of services are available "close by" that location. For example, given their location, users might want to query the system for the closest Automatic Teller Machine (ATM) or gas station. The number of descriptive terms for possible services is almost unbounded. This registry tries to identify common terms that are likely to be useful for communications devices. The terms roughly correspond to the level of details of location descriptions and icons found on geographic maps, for example, and are meant to be in common use across a variety of cultures and countries. In many cases, a service might be described by multiple terms that apply at the same time. For example, the combination of "restaurant" and "airport" is immediately recognizable. This registry makes no attempt to limit the number of terms that can be used to describe a single service or to restrict what combinations are allowed. Common sense is probably a better guide here; the authors would not want to rule out creative business models such as combinations of "parking" and "restaurant" or "bar" and "hospital". The number of terms that can be used within the same protocol element is left to the protocol description. This document does not describe how the values of the registry are to be used, as this description is provided by other documents. 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. Location-based services When not obvious, the definition of a particular service will be specified in the future. In the following we enumerate a sub-set of the most common location-based services, some of which are also present in [RFC4589]. urn:service:business - business.convention-center Forte & Schulzrinne Expires September 24, 2009 [Page 3] Internet-Draft Service Classification March 2009 urn:service:communication - communication.internet.80211 - communication.internet.80216 - communication.internet.8023 - communication.public-phone urn:service:cultural - cultural.art-gallery - cultural.library - cultural.monument - cultural.museum - cultural.theater urn:service:education - education.college - education.day-care-center - education.nursery - education.primary-school - education.school - education.secondary-school urn:service:entertainment - entertainment.arena - entertainment.basketball-court - entertainment.bingo-hall - entertainment.cinema - entertainment.club Forte & Schulzrinne Expires September 24, 2009 [Page 4] Internet-Draft Service Classification March 2009 - entertainment.field.hockey - entertainment.field.soccer - entertainment.park - entertainment.stadium - entertainment.stadium.baseball - entertainment.stadium.football - entertainment.stadium.soccer urn:service:financial - financial.atm - financial.bank urn:service:food - food.bar - food.cafe - food.pizza - food.restaurant.creole - food.restaurant.de - food.restaurant.es - food.restaurant.fr - food.restaurant.it - food.restaurant.other - food.restaurant.us [Generally speaking, one "restaurant" entry per country can be added, each with its own country suffix. Suffixes to be used here are specified in [ISO3166].] urn:service:fuel Forte & Schulzrinne Expires September 24, 2009 [Page 5] Internet-Draft Service Classification March 2009 - fuel.electricity-station - fuel.gas-station - fuel.hydrogen-station urn:service:government - government.military-base - government.prison urn:service:lodging - lodging.bed-and-breakfast - lodging.hotel - lodging.motel urn:service:medical - medical.dentist - medical.emergency-room - medical.hospital urn:service:religious - religious.church.catholic - religious.church.mormon - religious.church.protestant urn:service:retail - retail.bakery - retail.barber - retail.books - retail.butcher - retail.car-repair Forte & Schulzrinne Expires September 24, 2009 [Page 6] Internet-Draft Service Classification March 2009 - retail.clothing - retail.electronics - retail.fish - retail.flowers - retail.food - retail.games - retail.glass - retail.jewelry - retail.movies - retail.music - retail.news - retail.optician - retail.other - retail.shoes - retail.shopping-mall - retail.spirits - retail.tailor - retail.travel urn:service:transportation - transportation.airport - transportation.bycicle-rental - transportation.bus-stop - transportation.car-rental - transportation.mechanic Forte & Schulzrinne Expires September 24, 2009 [Page 7] Internet-Draft Service Classification March 2009 - transportation.parking - transportation.port - transportation.subway - transportation.taxi-stand - transportation.train-station 4. Guidelines for the creation of new top-level services The number of top-level services that can be defined is almost unbounded. New services, however, SHOULD at least satisfy the following guidelines. - The service has to be of general interest; - Not 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. Schema This registry can be used as a list of tokens, to be referenced by appropriate protocols that accept textual tokens. [SCHEMA TO BE DEFINED.] 6. IANA Considerations 6.1. Registering tokens This document creates new IANA registries for location-based services as listed in Section 3, starting with 'urn:service:business.convention-center' and finishing with 'urn:service:travel.motel'. IANA will maintain this registry both in the form of an XML schema and a list of tokens, with the same content. Forte & Schulzrinne Expires September 24, 2009 [Page 8] Internet-Draft Service Classification March 2009 Following the policies outline in [RFC2434], new tokens are assigned after Expert Review. The Expert Reviewer will generally consult the IETF GEOPRIV working group mailing list or its designated successor. Updates or deletions of tokens from the registration follow the same procedures. The expert review should be guided by a few common sense considerations. For example, tokens should be well- defined and widely recognized. The expert's support of IANA will include providing IANA with the new token(s) when the update is provided only in the form of a schema, and providing IANA with the new schema element(s) when the update is provided only in the form of a token. Each registration must include the name of the token. For the most appropriate terminology in defining token names for new services, the official UN classification [ISICrev3] must be consulted first. If no entry is present for the new service in the UN classification, then a new term can be defined. To ensure widespread usability across protocols, tokens MUST follow the character set restrictions for XML Names [XML]. 6.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-service URI: urn:ietf:params:xml:ns:location-service Description: This is the XML namespace for XML elements defined by this draft to describe location services within XML documents. Registrant Contact: IETF, GEOPRIV working group, geopriv@ietf.org, Henning Schulzrinne, hgs@cs.columbia.edu XML: [TO BE DEFINED] 6.3. Schema Registration for Schema urn:ietf:params:xml:ns:location-service URI: urn:ietf:params:xml:ns:location-service Registrant Contact: IESG XML: [TO BE DEFINED.] 7. Internationalization Considerations The service values listed in this document MUST NOT be presented to Forte & Schulzrinne Expires September 24, 2009 [Page 9] Internet-Draft Service Classification March 2009 the user. The values therefore have the characteristic of tokens or tags and no internationalization support is required. 8. Security Considerations This document defines a registry for location-based services and as such does not raise security issues. 9. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types Registry", July 2006. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", October 1998. [ISO3166] International Organization for Standardization (ISO), "English country names and code elements", July 2006. [ISICrev3] United Nations (UN), statistics division, "Alphabetical index for ISIC Rev.3", 2007. [XML] Sperberg-McQueen, C., Maler, E., Bray, T., Paoli, J., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", February 2004. Authors' Addresses Andrea G. Forte Columbia University Department of Computer Science 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA Email: andreaf@cs.columbia.edu Forte & Schulzrinne Expires September 24, 2009 [Page 10] Internet-Draft Service Classification March 2009 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 September 24, 2009 [Page 11]