Network Working Group A. Forte Internet-Draft H. Schulzrinne Intended status: Standards Track Columbia University Expires: November 28, 2008 May 27, 2008 Classification of Location-based Services draft-forte-ecrit-service-classification-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of 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 November 28, 2008. 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 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). Forte & Schulzrinne Expires November 28, 2008 [Page 1] Internet-Draft Service Classification May 2008 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 3. Location-based services . . . . . . . . . . . . . . . . . . . 4 4. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 5.1. Registering tokens . . . . . . . . . . . . . . . . . . . . 8 5.2. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:location-service . . . . . . . . . 9 5.3. Schema Registration for Schema urn:ietf:params:xml:ns:location-service . . . . . . . . . 9 6. Internationalization Considerations . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 10 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Intellectual Property and Copyright Statements . . . . . . . . . . 12 Forte & Schulzrinne Expires November 28, 2008 [Page 2] Internet-Draft Service Classification May 2008 1. Introduction This document creates a registry for service tokens. 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 ATM machine or gas station. Naturally, 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. The use of tokens (i.e., protocol constants) makes it easier to build systems across multiple languages. A user interface can readily translate a finite set of tokens to user-appropriate textual or iconic representations. Protocols using this registry are encouraged to provide additional mechanisms to accommodate services not currently registered via free-text fields with appropriate language and character set labeling. 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]. Forte & Schulzrinne Expires November 28, 2008 [Page 3] Internet-Draft Service Classification May 2008 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]. service.business - business.convention-center service.communication - communication.internet.80211 - communication.internet.80216 - communication.internet.8023 - communication.public-phone service.cultural - cultural.art-gallery - cultural.library - cultural.monument - cultural.museum - cultural.theater service.education - education.classroom - education.day-care-center - education.nursery - education.school service.entertainment - entertainment.arena - entertainment.basketball-court Forte & Schulzrinne Expires November 28, 2008 [Page 4] Internet-Draft Service Classification May 2008 - entertainment.bingo-hall - entertainment.cinema - entertainment.club - entertainment.field.hockey - entertainment.field.soccer - entertainment.park - entertainment.stadium - entertainment.stadium.baseball - entertainment.stadium.football service.financial - financial.atm - financial.bank service.food - food.bar - food.cafe - food.restaurant.creole - food.restaurant.de - food.restaurant.es - food.restaurant.fr - food.restaurant.it - food.restaurant.northern - food.restaurant.other - food.restaurant.southern - food.restaurant.us Forte & Schulzrinne Expires November 28, 2008 [Page 5] Internet-Draft Service Classification May 2008 [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].] service.fuel - fuel.electricity-station - fuel.gas-station - fuel.hydrogen-station service.government - government.military-base - government.prison service.medical - medical.dentist - medical.emergency-room - medical.hospital service.religious - religious.church.catholic - religious.church.episcopalian - religious.church.latter-saints - religious.church.lutheran - religious.church.pentecostal - religious.mosque - religious.temple service.retail - retail.bakery - retail.barber Forte & Schulzrinne Expires November 28, 2008 [Page 6] Internet-Draft Service Classification May 2008 - retail.books - retail.butcher - retail.car-repair - 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 service.transportation - transportation.airport - transportation.bycicle-rental Forte & Schulzrinne Expires November 28, 2008 [Page 7] Internet-Draft Service Classification May 2008 - transportation.bus-stop - transportation.car-rental - transportation.mechanic - transportation.parking - transportation.port - transportation.subway - transportation.taxi-stand - transportation.train-station service.travel - travel.bed-and-breakfast - travel.hotel - travel.motel 4. Schema This registry can be used in two ways, first, as a list of tokens, to be referenced by appropriate protocols that accept textual tokens, and second, as a schema, with its own namespace, referenced by other schema, either explicitly or via namespace="##other". [SCHEMA TO BE DEFINED.] 5. IANA Considerations 5.1. Registering tokens This document creates new IANA registries for location-based services as listed in Section 3, starting with 'service.business.convention- center' and finishing with '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. Following the policies outline in [RFC2434], new tokens are assigned after Expert Review. The Expert Reviewer will generally consult the Forte & Schulzrinne Expires November 28, 2008 [Page 8] Internet-Draft Service Classification May 2008 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]. 5.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] 5.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.] 6. Internationalization Considerations The service values listed in this document MUST NOT be presented to the user. The values therefore have the characteristic of tokens or tags and no internationalization support is required. Forte & Schulzrinne Expires November 28, 2008 [Page 9] Internet-Draft Service Classification May 2008 7. Security Considerations This document defines a registry for location-based services and as such does not raise security issues. 8. 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 November 28, 2008 [Page 10] Internet-Draft Service Classification May 2008 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 November 28, 2008 [Page 11] Internet-Draft Service Classification May 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Forte & Schulzrinne Expires November 28, 2008 [Page 12]