< draft-forte-ecrit-service-classification-02.txt		draft-forte-ecrit-service-classification-03.txt >
	Network Working Group A. Forte		Network Working Group A. Forte
	Internet-Draft H. Schulzrinne		Internet-Draft H. Schulzrinne
	Intended status: Standards Track Columbia University		Intended status: Standards Track Columbia University
	Expires: September 24, 2009 March 23, 2009		Expires: July 5, 2009 January 2009
	Labels for Common Location-Based Services		Labels for Common Location-Based Services
	draft-forte-ecrit-service-classification-02.txt		draft-forte-ecrit-service-classification-03.txt
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted to IETF in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 32 ¶		skipping to change at page 1, line 32 ¶
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 24, 2009.		This Internet-Draft will expire on July 5, 2009.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	and restrictions with respect to this document.		and restrictions with respect to this document.
	Abstract		Abstract
	This document creates a registry for describing the types of services		This document creates a registry for describing the types of services
	available at a specific location. The registry is then referenced by		available at a specific location. The registry is expected to be
	other protocols that need a common set of service terms as protocol		referenced by other protocols that need a common set of service terms
	constants. In particular, we define location-based service as either		as protocol constants. In particular, we define location-based
	a point at a specific geographic location (e.g., bus stop) or a		service as either a point at a specific geographic location (e.g.,
	service covering a specific region (e.g., pizza delivery).		bus stop) or a service covering a specific region (e.g., pizza
			delivery).
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3		2. Requirements notation . . . . . . . . . . . . . . . . . . . . 3
	3. Location-based services . . . . . . . . . . . . . . . . . . . 3		3. Location-based services . . . . . . . . . . . . . . . . . . . 3
	4. Guidelines for the creation of new top-level services . . . . 8		4. Guidelines for the creation of new top-level services . . . . 10
	5. Schema . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8		5.1. Registering new tokens . . . . . . . . . . . . . . . . . . 11
	6.1. Registering tokens . . . . . . . . . . . . . . . . . . . . 8		5.2. Internationalization Considerations . . . . . . . . . . . 11
	6.2. URN Sub-Namespace Registration for		5.3. Security Considerations . . . . . . . . . . . . . . . . . 11
	urn:ietf:params:xml:ns:location-service . . . . . . . . . 9		6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	6.3. Schema Registration for Schema		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
	urn:ietf:params:xml:ns:location-service . . . . . . . . . 9
	7. Internationalization Considerations . . . . . . . . . . . . . 9
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction		1. Introduction
	We anticipate that the network, through configuration or management		Many mobile devices are now equipped to determine the user's
	protocols, tells a mobile device what kind of location it finds		geographic location, either through GPS, cell-tower mapping or a
	itself in and what kind of services are available "close by" that		network-based triangulation mechanism. Once location information is
	location. For example, given their location, users might want to		available, it is natural to want to look up near-by places that
	query the system for the closest Automatic Teller Machine (ATM) or		provide a specific service, sometimes called points-of-interest
	gas station.		(POI). Examples of such services include restaurants, stores,
			hospitals, automatic teller machines and museums.
	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		To allow such systems to operate across large geographic areas and
	apply at the same time. For example, the combination of "restaurant"		for multiple languages, it is useful to define a common set of terms,
	and "airport" is immediately recognizable. This registry makes no		so that the same service is labeled with the same token regardless of
	attempt to limit the number of terms that can be used to describe a		who created a particular location service. The number of different
	single service or to restrict what combinations are allowed. Common		labels is clearly potentially very large, but only a relatively small
	sense is probably a better guide here; the authors would not want to		subset of common services is of particular interest to mobile users,
	rule out creative business models such as combinations of "parking"		such as travelers and commuters. This document focuses on labels
	and "restaurant" or "bar" and "hospital". The number of terms that		commonly found on maps or in navigation devices.
	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		This document creates a registry of service labels and an initial set
	be used, as this description is provided by other documents.		of values. The registry is protocol-agnostic and should work for all
			protocols that can handle alphanumeric strings, including LoST
			[RFC5222].
	2. Requirements notation		2. Requirements notation
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	3. Location-based services		3. Location-based services
	When not obvious, the definition of a particular service will be		When not obvious, the definition of a particular service will be
	specified in the future. In the following we enumerate a sub-set of		specified in the future. In the following we enumerate a sub-set of
	the most common location-based services, some of which are also		the most common location-based services, some of which are also
	present in [RFC4589].		present in [RFC4589].
	urn:service:business		urn:service:business
	- business.convention-center		- business.convention-center
	urn:service:communication		urn:service:communication
	- communication.internet.80211		- communication.internet.802.-11
	- communication.internet.80216
	- communication.internet.8023		- communication.internet.802.-16
			- communication.internet.802.-3
	- communication.public-phone		- communication.public-phone
	urn:service:cultural		urn:service:cultural
	- cultural.art-gallery		- cultural.art-gallery
	- cultural.library		- cultural.library
	- cultural.monument		- cultural.monument
	skipping to change at page 4, line 49 ¶		skipping to change at page 4, line 42 ¶
	- education.secondary-school		- education.secondary-school
	urn:service:entertainment		urn:service:entertainment
	- entertainment.arena		- entertainment.arena
	- entertainment.basketball-court		- entertainment.basketball-court
	- entertainment.bingo-hall		- entertainment.bingo-hall
			- entertainment.casino
	- entertainment.cinema		- entertainment.cinema
	- entertainment.club		- entertainment.club
	- entertainment.field.hockey
	- entertainment.field.soccer		- entertainment.field.ice-hockey
			- entertainment.field.soccer
	- entertainment.park		- entertainment.park
			- entertainment.race-track
	- entertainment.stadium		- entertainment.stadium
	- entertainment.stadium.baseball		- entertainment.stadium.baseball
	- entertainment.stadium.football		- entertainment.stadium.football
	- entertainment.stadium.soccer		- entertainment.stadium.soccer
	urn:service:financial		urn:service:financial
	- financial.atm		- financial.atm
	- financial.bank		- financial.bank
			- financial.currency-exchange
	urn:service:food		urn:service:food
			- food.bakery
	- food.bar		- food.bar
			- food.beer-garden
	- food.cafe		- food.cafe
			- food.cafeteria
			- food.coffee-house
			- food.doughnut-shop
			- food.fast-service
			- food.ice-cream-parlor
			- food.pancake-house
	- food.pizza		- food.pizza
	- food.restaurant.creole		- 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.de
			- food.restaurant.diner
			- food.restaurant.drive-in
	- food.restaurant.es		- food.restaurant.es
			- food.restaurant.ethnic
			- food.restaurant.fast-casual
			- food.restaurant.fast-food
	- food.restaurant.fr		- food.restaurant.fr
			- food.restaurant.gr
			- food.restaurant.hamburger
			- food.restaurant.hot-dog
	- food.restaurant.it		- food.restaurant.it
			- food.restaurant.kosher
			- food.restaurant.kr
	- food.restaurant.other		- 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.us
			- food.restaurant.vegan
			- food.restaurant.vegetarian
	[Generally speaking, one "restaurant" entry per country can be		[Generally speaking, one "restaurant" entry per country can be
	added, each with its own country suffix. Suffixes to be used here		added, each with its own country suffix. Suffixes to be used here
	are specified in [ISO3166].]		are specified in [ISO3166].]
	urn:service:fuel		urn:service:fuel
			- fuel.biodiesel-station
			- fuel.cng-station
			- fuel.diesel-station
	- fuel.electricity-station		- fuel.electricity-station
	- fuel.gas-station		- fuel.ethanol-station
			- fuel.gasoline-station
	- fuel.hydrogen-station		- fuel.hydrogen-station
			- fuel.lng-station
			- fuel.lpg-station
	urn:service:government		urn:service:government
			- government.courthouse
	- government.military-base		- government.military-base
	- government.prison		- government.prison
	urn:service:lodging		urn:service:lodging
	- lodging.bed-and-breakfast		- lodging.bed-and-breakfast
			- lodging.hostel
	- lodging.hotel		- lodging.hotel
	- lodging.motel		- lodging.motel
	urn:service:medical		urn:service:medical
	- medical.dentist		- medical.dentist
	- medical.emergency-room		- medical.emergency-room
	- medical.hospital		- medical.hospital
			- medical.veterinarian
	urn:service:religious		urn:service:religious
	- religious.church.catholic		- religious.church.adventist
	- religious.church.mormon		- 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.pentecostal
			- religious.church.presbyterian
	- religious.church.protestant		- 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		urn:service:retail
	- retail.bakery		- retail.bakery
	- retail.barber		- retail.barber
	- retail.books		- retail.books
	- retail.butcher		- retail.butcher
	skipping to change at page 8, line 4 ¶		skipping to change at page 10, line 37 ¶
	- transportation.airport		- transportation.airport
	- transportation.bycicle-rental		- transportation.bycicle-rental
	- transportation.bus-stop		- transportation.bus-stop
	- transportation.car-rental		- transportation.car-rental
	- transportation.mechanic		- transportation.mechanic
	- transportation.parking		- transportation.parking
	- transportation.port		- transportation.port
	- transportation.subway		- transportation.subway
	- transportation.taxi-stand		- transportation.taxi-stand
	- transportation.train-station		- transportation.train-station
	4. Guidelines for the creation of new top-level services		4. Guidelines for the creation of new top-level services
	The number of top-level services that can be defined is almost		The number of services that can be defined is very large. New
	unbounded. New services, however, SHOULD at least satisfy the		services, however, SHOULD at least satisfy the following guidelines.
	following guidelines.
	- The service has to be of general interest;		- The service has to be of general interest;
	- Not specific to a particular country or region;		- It should not be specific to a particular country or region;
	- The language in which the new service is defined MUST be English		- The language in which the new service is defined MUST be English
	(this is a protocol token, not meant to be shown to humans);		(this is a protocol token, not meant to be shown to humans);
	- The newly defined services SHOULD correspond to a standard		- The newly defined services SHOULD correspond to a standard
	statistical classification of enterprises or services, such as the		statistical classification of enterprises or services, such as the
	North American Industry Classification System (NAICS).		North American Industry Classification System (NAICS).
	5. Schema		5. IANA Considerations
	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		Registration template and URN scheme for emergency and non-emergency
			services have been defined in [RFC5031] in Sections 3 and 4,
			respectively.
	6.1. Registering tokens		5.1. Registering new tokens
	This document creates new IANA registries for location-based services		This document creates new IANA registries for location-based services
	as listed in Section 3, starting with		as listed in Section 3, starting with
	'urn:service:business.convention-center' and finishing with		'urn:service:business.convention-center' and finishing with
	'urn:service:travel.motel'.		'urn:service:transportation.train-station'.
	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 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.]		Aside from the labels defined here, document
			[draft-ietf-ecrit-service-urn-policy] defines the registration policy
			for new service-identifying labels.
	7. Internationalization Considerations		5.2. Internationalization Considerations
	The service values listed in this document MUST NOT be presented to		The service values listed in this document MUST NOT be presented to
	the user. The values therefore have the characteristic of tokens or		the user. The values therefore have the characteristic of tokens or
	tags and no internationalization support is required.		tags and no internationalization support is required.
	8. Security Considerations		5.3. Security Considerations
	This document defines a registry for location-based services and as		This document defines a registry for location-based services and as
	such does not raise security issues.		such does not raise security issues. The same security
			considerations as in [RFC5031] apply.
	9. References		6. References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		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		[RFC4589] Schulzrinne, H. and H. Tschofenig, "Location Types
	Registry", July 2006.		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),		[ISO3166] International Organization for Standardization (ISO),
	"English country names and code elements", July 2006.		"English country names and code elements", July 2006.
	[ISICrev3]		[draft-ietf-ecrit-service-urn-policy]
	United Nations (UN), statistics division, "Alphabetical		Forte, A. and H. Schulzrinne, "Policy for defining new
	index for ISIC Rev.3", 2007.		service-identifying labels for non-emergency services
			(Internet draft - work in progress)", December 2009.
	[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		Authors' Addresses
	Andrea G. Forte		Andrea G. Forte
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	1214 Amsterdam Avenue, MC 0401		1214 Amsterdam Avenue, MC 0401
	New York, NY 10027		New York, NY 10027
	USA		USA
End of changes. 50 change blocks.
	128 lines changed or deleted		208 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/