Network Working Group                                           A. Forte
Internet-Draft                                            H. Schulzrinne
Intended status: Standards Track                     Columbia University
Expires: September 24, July 5, 2009                               March 23,                                       January 2009

               Labels for Common Location-Based Services
            draft-forte-ecrit-service-classification-02.txt
            draft-forte-ecrit-service-classification-03.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, July 5, 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 expected to be
   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).

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 10
   5.  Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . .  8
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  8
     6.1. 11
     5.1.  Registering new 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. 11
     5.2.  Internationalization Considerations  . . . . . . . . . . . . .  9
   8. 11
     5.3.  Security Considerations  . . . . . . . . . . . . . . . . . . . 10
   9. 11
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 11
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 12

1.  Introduction

   We anticipate that

   Many mobile devices are now equipped to determine the network, user's
   geographic location, either through configuration GPS, cell-tower mapping or management
   protocols, tells a mobile device what kind of
   network-based triangulation mechanism.  Once location information is
   available, 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 natural to be useful for communications devices.  The terms roughly
   correspond want to the level of details look up near-by places that
   provide a specific service, sometimes called points-of-interest
   (POI).  Examples of location descriptions such services include restaurants, stores,
   hospitals, automatic teller machines and icons
   found on museums.

   To allow such systems to operate across large geographic maps, for example, areas and are meant
   for multiple languages, it is useful to be in common
   use across define a variety common set of cultures and countries.

   In many cases, a service might be described by multiple terms terms,
   so that
   apply at the same time.  For example, the combination of "restaurant"
   and "airport" service is immediately recognizable.  This registry makes no
   attempt to limit labeled with the number same token regardless of terms that can be used to describe
   who created a
   single service or to restrict what combinations are allowed.  Common
   sense particular location service.  The number of different
   labels is probably clearly potentially very large, but only a better guide here; the authors would not want relatively small
   subset of common services is of particular interest to
   rule out creative business models mobile users,
   such as combinations of "parking" travelers and "restaurant" commuters.  This document focuses on labels
   commonly found on maps or "bar" and "hospital".  The number of terms that
   can be used within the same protocol element is left to the protocol
   description. in navigation devices.

   This document does not describe how the values creates a registry of the service labels and an initial set
   of values.  The registry are to
   be used, as this description is provided by other documents. protocol-agnostic and should work for all
   protocols that can handle alphanumeric strings, including LoST
   [RFC5222].

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

   urn:service:communication

     - communication.internet.80211 communication.internet.802.-11

     - communication.internet.80216 communication.internet.802.-16
     - communication.internet.8023 communication.internet.802.-3

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

     - entertainment.cinema

     - entertainment.club

     - entertainment.field.hockey entertainment.field.ice-hockey

     - entertainment.field.soccer
     - entertainment.park

     - entertainment.race-track

     - entertainment.stadium

     - entertainment.stadium.baseball

     - entertainment.stadium.football

     - entertainment.stadium.soccer

   urn:service:financial

     - financial.atm

     - financial.bank

     - financial.currency-exchange

   urn:service:food

     - food.bakery

     - food.bar

     - food.beer-garden

     - food.cafe

     - food.cafeteria

     - food.coffee-house

     - food.doughnut-shop

     - food.fast-service

     - food.ice-cream-parlor

     - food.pancake-house

     - food.pizza

     - food.pub

     - food.root-beer-stand
     - food.street-vendor

     - food.tea-house

     - food.restaurant.barbecue

     - food.restaurant.buffet

     - food.restaurant.cn

     - food.restaurant.creole [Louisiana cuisine]

     - food.restaurant.de

     - food.restaurant.diner

     - food.restaurant.drive-in

     - food.restaurant.es

     - food.restaurant.ethnic

     - food.restaurant.fast-casual

     - food.restaurant.fast-food

     - food.restaurant.fr

     - food.restaurant.gr

     - food.restaurant.hamburger

     - food.restaurant.hot-dog

     - food.restaurant.it

     - food.restaurant.kosher

     - food.restaurant.kr

     - food.restaurant.other

     - food.restaurant.pizzeria

     - food.restaurant.revolving

     - food.restaurant.seafood
     - food.restaurant.steakhouse

     - food.restaurant.tavern

     - food.restaurant.theme [Such as Disney restaurants]

     - food.restaurant.us

     - food.restaurant.vegan

     - food.restaurant.vegetarian

      [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.biodiesel-station

     - fuel.cng-station

     - fuel.diesel-station

     - fuel.electricity-station

     - fuel.gas-station fuel.ethanol-station

     - fuel.gasoline-station

     - fuel.hydrogen-station

     - fuel.lng-station

     - fuel.lpg-station

   urn:service:government

     - government.courthouse

     - government.military-base

     - government.prison

   urn:service:lodging

     - lodging.bed-and-breakfast
     - lodging.hostel

     - lodging.hotel

     - lodging.motel

   urn:service:medical

     - medical.dentist

     - medical.emergency-room

     - medical.hospital

     - medical.veterinarian

   urn:service:religious

     - religious.church.catholic religious.church.adventist

     - religious.church.anabaptist

     - religious.church.anglican

     - religious.church.baptist.national

     - religious.church.baptist.southern

     - religious.church.congregationalist

     - religious.church.episcopalian

     - religious.church.greek-orthodox

     - religious.church.latter-day-saints [Also known as Mormon church]

     - religious.church.lutheran

     - religious.church.methodist

     - religious.church.mormon religious.church.pentecostal

     - religious.church.presbyterian

     - religious.church.protestant

      ["Protestant" comprises: Adventist, Anabaptist, Baptist,
   Congregationalist, Lutheran, Methodist, Presbyterian, Reformed,
   Pentecostal, Restorationist]

     - religious.church.reformed

     - religious.church.restorationist

     - religious.church.roman-catholic

     - religious.house-of-worship

     - religious.kingdom-hall

     - religious.mosque

     - religious.synagogue

     - religious.temple.buddhist

     - religious.temple.hindu

     - religious.temple.masonic

   urn:service:retail

     - retail.bakery

     - 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

     - transportation.bycicle-rental

     - transportation.bus-stop

     - transportation.car-rental

     - transportation.mechanic

     - 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. very large.  New
   services, however, SHOULD at least satisfy the following guidelines.

   - The service has to be of general interest;

   - Not It should not be 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.

   Registration template and URN scheme for emergency and non-emergency
   services have been defined in [RFC5031] in Sections 3 and 4,
   respectively.

5.1.  Registering new 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.

   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
   'urn:service:transportation.train-station'.

   Aside 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- labels 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 here, document
   [draft-ietf-ecrit-service-urn-policy] defines the form of a token.

   Each registration must include the name of the token.  For the most
   appropriate terminology in defining token names policy
   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. service-identifying labels.

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

8.

5.3.  Security Considerations

   This document defines a registry for location-based services and as
   such does not raise security issues.

9.  The same security
   considerations as in [RFC5031] apply.

6.  References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC5031]  Schulzrinne, H., "A Uniform Resource Name (URN) for
              Emergency and Other Well-Known Services", RFC 5031,
              January 2008.

   [RFC5222]  Hardie, T., Newton, A., Schulzrinne, H., and H.
              Tschofenig, "LoST: A Location-to-Service Translation
              Protocol", RFC 5222, August 2008.

   [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.,

   [draft-ietf-ecrit-service-urn-policy]
              Forte, A. and
              F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third
              Edition)", February 2004. H. Schulzrinne, "Policy for defining new
              service-identifying labels for non-emergency services
              (Internet draft - work in progress)", December 2009.

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

   Henning Schulzrinne
   Columbia University
   Department of Computer Science
   1214 Amsterdam Avenue, MC 0401
   New York, NY  10027
   USA

   Email: hgs@cs.columbia.edu