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]