Network Working Group                                           A. Forte
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                     Columbia University
Expires: May 7, 2009                                    November 3, 2008


               Classification of Location-based Services
            draft-forte-ecrit-service-classification-01.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 May 7, 2009.

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


Internet-Draft           Service Classification            November 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 May 7, 2009                  [Page 2]


Internet-Draft           Service Classification            November 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 May 7, 2009                  [Page 3]


Internet-Draft           Service Classification            November 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].

   urn:service:business

     - business.convention-center

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

     - education.day-care-center

     - education.nursery

     - education.school

   urn:service:entertainment

     - entertainment.arena

     - entertainment.basketball-court



Forte & Schulzrinne        Expires May 7, 2009                  [Page 4]


Internet-Draft           Service Classification            November 2008


     - entertainment.bingo-hall

     - entertainment.cinema

     - entertainment.club

     - entertainment.field.hockey

     - entertainment.field.soccer

     - entertainment.park

     - entertainment.stadium

     - entertainment.stadium.baseball

     - entertainment.stadium.football

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

     - food.restaurant.other

     - food.restaurant.southern




Forte & Schulzrinne        Expires May 7, 2009                  [Page 5]


Internet-Draft           Service Classification            November 2008


     - 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

     - fuel.electricity-station

     - fuel.gas-station

     - fuel.hydrogen-station

   urn:service:government

     - government.military-base

     - government.prison

   urn:service:medical

     - medical.dentist

     - medical.emergency-room

     - medical.hospital

   urn:service:religious

     - religious.church.catholic

     - religious.church.episcopalian

     - religious.church.latter-saints

     - religious.church.lutheran

     - religious.church.pentecostal

     - religious.mosque

     - religious.temple

   urn:service:retail

     - retail.bakery




Forte & Schulzrinne        Expires May 7, 2009                  [Page 6]


Internet-Draft           Service Classification            November 2008


     - retail.barber

     - 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

   urn:service:transportation

     - transportation.airport




Forte & Schulzrinne        Expires May 7, 2009                  [Page 7]


Internet-Draft           Service Classification            November 2008


     - transportation.bycicle-rental

     - transportation.bus-stop

     - transportation.car-rental

     - transportation.mechanic

     - transportation.parking

     - transportation.port

     - transportation.subway

     - transportation.taxi-stand

     - transportation.train-station

   urn: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
   '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 May 7, 2009                  [Page 8]


Internet-Draft           Service Classification            November 2008


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

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



Forte & Schulzrinne        Expires May 7, 2009                  [Page 9]


Internet-Draft           Service Classification            November 2008


   the user.  The values therefore have the characteristic of tokens or
   tags and no internationalization support is required.


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 May 7, 2009                 [Page 10]


Internet-Draft           Service Classification            November 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 May 7, 2009                 [Page 11]


Internet-Draft           Service Classification            November 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 May 7, 2009                 [Page 12]