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]