< draft-schulzrinne-geopriv-relo-02.txt		draft-schulzrinne-geopriv-relo-03.txt >
	GEOPRIV H. Schulzrinne		GEOPRIV H. Schulzrinne
	Internet-Draft Columbia U.		Internet-Draft Columbia U.
	Intended status: Standards Track December 17, 2006		Intended status: Standards Track March 4, 2007
	Expires: June 20, 2007		Expires: September 5, 2007
	RELO: Retrieving End System Location Information		RELO: Retrieving End System Location Information
	draft-schulzrinne-geopriv-relo-02.txt		draft-schulzrinne-geopriv-relo-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		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		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.		aware will be disclosed, in accordance with Section 6 of 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
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	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 June 20, 2007.		This Internet-Draft will expire on September 5, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	In some network configurations, it is desirable for the end system to		In some network configurations, it is desirable for the end system to
	be able to obtain its geodetic or civic location using an		be able to obtain its geodetic or civic location using an
	application-layer protocol. This document describes RELO (Retrieving		application-layer protocol. This document describes RELO (Retrieving
	End system LOcation), a simple, HTTP-based stateless protocol profile		End system LOcation), a simple, HTTP-based stateless protocol profile
	that fulfills this need.		that fulfills this need.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		3. Protocol Description . . . . . . . . . . . . . . . . . . . . . 3
	3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4		3.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.2. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3.2. Query . . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3.3. Response . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.3. Response . . . . . . . . . . . . . . . . . . . . . . . . . 7
	4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7		3.4. Signed Location . . . . . . . . . . . . . . . . . . . . . 8
	4.1. S-NAPTR Application Service Tag . . . . . . . . . . . . . 7		3.5. Error Reporting . . . . . . . . . . . . . . . . . . . . . 8
	4.2. HTTP Message Header 'Subscribe' . . . . . . . . . . . . . 7		3.6. Client Authentication . . . . . . . . . . . . . . . . . . 8
	4.3. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 7		4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 8		4.1. S-NAPTR Application Service Tag . . . . . . . . . . . . . 8
	6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. HTTP Message Header 'Subscribe' . . . . . . . . . . . . . 9
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.3. MIME Type . . . . . . . . . . . . . . . . . . . . . . . . 9
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 9		5. Security Considerations . . . . . . . . . . . . . . . . . . . 10
	7.2. Informative References . . . . . . . . . . . . . . . . . . 10		6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	Intellectual Property and Copyright Statements . . . . . . . . . . 11		7.1. Normative References . . . . . . . . . . . . . . . . . . . 11
			7.2. Informative References . . . . . . . . . . . . . . . . . . 12
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 12
			Intellectual Property and Copyright Statements . . . . . . . . . . 13
	1. Introduction		1. Introduction
	The RELO HTTP protocol usage allows end systems (devices) to obtain		The RELO HTTP protocol usage allows end systems (devices) to obtain
	information about their current geodetic (longitude, latitude) or		information about their current geodetic (longitude, latitude) or
	civic (jurisdictional or postal street address) location, based on		civic (jurisdictional or postal street address) location, based on
	their Internet Protocol address or possibly other identifiers. The		their Internet Protocol address or possibly other identifiers. The
	protocol uses HTTP [3] to retrieve the information. The location		protocol uses HTTP [3] to retrieve the information. The location
	information can be returned by value or by reference, either for		information can be returned by value or by reference, either for
	retrieval or for event notification by subscription.		retrieval or for event notification by subscription.
	skipping to change at page 3, line 42 ¶		skipping to change at page 3, line 42 ¶
	to allow non-proxied connections to the LIS only.		to allow non-proxied connections to the LIS only.
	2. Terminology		2. Terminology
	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 RFC 2119 [1].		document are to be interpreted as described in RFC 2119 [1].
	This document reuses terminology introduced by RFC 3693 [5] and [11].		This document reuses terminology introduced by RFC 3693 [5] and [11].
	3. Overview		3. Protocol Description
	This section describes the Location Information Server (LIS)		This section describes the Location Information Server (LIS)
	discovery procedure (see Section 3.1), the query message (see		discovery procedure (see Section 3.1), the query message (see
	Section 3.2) and the response message (see Section 3.3).		Section 3.2) and the response message (see Section 3.3).
	3.1. Discovery		3.1. Discovery
	The URI for the location server is conveyed via DHCP (not described		The URI for the location server is conveyed via DHCP (not described
	here) or DNS (S-NAPTR) [7]. The domain is determined from the domain		here) or DNS (S-NAPTR) [7]. The domain is determined from the domain
	name of the end host, typically conveyed as part of the configuration		name of the end host, typically conveyed as part of the configuration
	skipping to change at page 4, line 42 ¶		skipping to change at page 4, line 42 ¶
	does not change the state of the resource, GET is the appropriate		does not change the state of the resource, GET is the appropriate
	method.)		method.)
	Unless other identifiers are provided, the end system is identified		Unless other identifiers are provided, the end system is identified
	by its IP address, contained in the IP packets carrying the HTTP		by its IP address, contained in the IP packets carrying the HTTP
	request. If the querier is behind a NAT or firewall, the server will		request. If the querier is behind a NAT or firewall, the server will
	see the querier's public IP address and use that address to identify		see the querier's public IP address and use that address to identify
	the end system. In those cases, the location of the network		the end system. In those cases, the location of the network
	termination equipment, such as the DSL modem or 802.11 access point,		termination equipment, such as the DSL modem or 802.11 access point,
	will be returned, not the actual location of the querier since the		will be returned, not the actual location of the querier since the
	LIS generally has no way to estimate that location. Other location		LIS generally has no way to estimate that location. Other network
	identifiers, such as those provided by CDP, LLDP or the MAC address,		identifiers, such as those provided by CDP, LLDP or the MAC address,
	can be provided; the client SHOULD include all such identifiers it		can be provided; the client SHOULD include all such identifiers it
	knows about. The server is free to choose the most appropriate		knows about. The server is free to choose the most appropriate
	identifier to determine the client location information and SHOULD		identifier to determine the client location information and SHOULD
	choose the one yielding the highest accuracy and reliability.		choose the one yielding the highest accuracy and reliability within
			the time limits provided by the 'within' parameter. If any of the
			network identifiers or other parameters have the wrong syntax, the
			server returns a 400 (Bad Request) error, with additional information
			on the syntax error provided in the entity body and the HTTP Reason-
			Phrase.
	by The 'by' parameter indicates whether the client would like to		by The 'by' parameter indicates whether the client would prefer to
	obtain a value ('value') or a reference ('reference'). The		obtain a value ('value') or a reference ('reference'). The
	default is 'value'.		default is 'value' if the LIS supports it, 'reference' otherwise.
			The client can restrict the type of location information returned
			via the HTTP Accept header in the request. If the server can only
			deliver a format not listed, it responds with a 406 (Not
			Acceptable) status code.
			within The 'within' parameter indicates the amount of time that the
			client is willing to wait for an answer, expressed as a positive
			decimal integer and measured in seconds, using the canonical
			representation of the XML 'decimal' primitive data type. If
			omitted, the LIS SHOULD return the most precise location
			information available.
	type The 'type' parameter indicates whether the client desires a		type The 'type' parameter indicates whether the client desires a
	'civic' or 'geo' address. The default is 'geo'.		'civic' or 'geo' address. The default is 'geo' if supported by
			the server and 'civic' otherwise. If a client requests one type
			of location information, but the server only has the other, the
			server MAY return that information instead, as the client can
			easily determine that this is the case. Alternatively, the LIS
			MAY return a 404 (Not Found) error, with an appropriate
			explanation. A client willing to accept both formats can either
			omit the 'type' parameter if it wants to only receive one type, or
			query for both types, even if one returns an error.
			retransmission-allowed The client uses the 'retransmission-allowed'
			parameter to request that the PIDF location object contains the
			corresponding parameter value. Only the string literals 'yes' and
			'no' are allowed. The default is 'no'.
			retention-expiry The client uses the 'retention-expiry' parameter to
			request that the PIDF-LO contains the corresponding usage rule.
			The value is an XML date time, as specified by PIDF-LO. If
			omitted, the defaults specified for PIDF-LO are used.
			external-ruleset The client uses the 'external-ruleset' parameter to
			request that the PIDF-LO contains the corresponding usage rule.
			The value is of XML type anyURI, as specified by PIDF-LO.
			note-well The client uses the 'note-well' parameter to request that
			the PIDF-LO contains the corresponding usage rule. The rule if of
			type XML string.
			note-well-lang The client uses the 'note-well-lang' parameter to
			request that the PIDF-LO 'note-well' element contains the
			corresponding language indication, using XML conventions.
	url The 'url' parameter is used only if a location location		url The 'url' parameter is used only if a location location
	reference URL is being renewed. It is ignored if the 'by=value'		reference URL is being renewed. It is ignored if the 'by=value'
	parameter is specified. The expiration time of the URL is		parameter is specified. The expiration time of the URL is
	updated, assuming that the secret agrees with that stored for the		updated, assuming that the secret agrees with that stored for the
	URL. If the parameter is not supplied, a new URL is created.		URL. If the parameter is not supplied, a new URL is created.
	expires The 'expires' parameter contains an XML dateTime string in		expires The 'expires' parameter contains an XML dateTime string in
	canonical (UTC) representation. It indicates the time that the		canonical (UTC) representation. It indicates the time that the
	requestor would like the location reference or value to expire.		requestor would like the location reference or value to expire.
	For values, the parameter sets the 'retention-expiry' data in		For values, the parameter sets the 'retention-expiry' data in
	PIDF-LO. An expiration date in the past immediately invalidates		PIDF-LO. An expiration date in the past immediately invalidates
	the URL. By default, the URL expires two hours after being		the URL. By default, the URL expires two hours after being
	issued.		issued.
	secret The 'secret' parameter allows the client to provide a		secret The 'secret' parameter allows the client to provide a
	password that controls access to the URL. When creating a new		password that controls access to the URL. When creating a new
	URL, the server stores that password with the URL for later		URL, the server stores that password with the URL for later
	modification. If not specified upon creation, the URL properties		modification. If not specified upon creation, the URL properties
	cannot be modified later.		cannot be modified later.
	mac The 'mac' parameter contains an IEEE IEEE MAC address written in		mac The 'mac' parameter contains an IEEE IEEE MAC address written in
	IEEE EUI-64 or EUI-48 notation, with lower-case hexadecimal		IEEE EUI-64 or EUI-48 notation, with lower-case hexadecimal
	characters separated by colons. An example is "0:3:fc:0:ca:27".		characters separated by colons. An example is "0:3:fc:0:ca:27".
			This is a network identifier.
	cdp The 'cdp' parameter contains a Cisco Discovery Protocol (CDP).		cdp The 'cdp' parameter contains a Cisco Discovery Protocol (CDP).
	The CDP identifier consists of the CDP device id, a colon and the		The CDP identifier consists of the CDP device id, a colon and the
	port ID. An example is cepsr-7-1:FastEthernet6/6.		port ID. An example is cepsr-7-1:FastEthernet6/6. This is
			network identifier.
	msap The 'msap' parameter identifies a MAC service access point,		msap The 'msap' parameter identifies a MAC service access point,
	typically a switch chassis and port. If derived from LLDP (IEEE		typically a switch chassis and port. If derived from LLDP (IEEE
	802.1ab), it is encoded in base64.		802.1ab), it is encoded in base64. This is a network identifier.
			assert The 'assert' parameter contains a PIDF-LO, e.g., derived via
			GPS, that the client would like the LIS to sign and store.
			Depending on the RELO parameters supplied, the server will return
			either a location reference or a, typically signed, location
			object. A server MAY return a 403 (Forbidden) response if the LIS
			does not want to allow this particular client to assert location
			information. If the assertion is granted, future requests for
			location for the combination of network identifiers (mac, msap,
			cdp, etc.) MAY return this location information, but a LIS MAY
			decide to only allow retrieval from the same IP address used for
			the assertion.
	Thus, a URL without a query string returns the current location		Thus, a URL without a query string returns the current location
	value, with a retention period of two hours, based on the client's IP		value, with a retention period of two hours, based on the client's IP
	address.		address. If several addresses are provided, it is left to the server
			to select the one that it has location information for. Due to the
			use of return routability, the use of the IP address is preferred.
	A query example is shown below:		A query example is shown below:
	http://example.com?type=civic&by=value&secret=bond007		http://example.com?type=civic&by=value&secret=bond007
	&expires=2007%2D01%2D20T23%3A10%3A01%0D%0A		&expires=2007%2D01%2D20T23%3A10%3A01%0D%0A
	Query URL for location object containing civic		Query URL for location object containing civic
	location information		location information
	This protocol does not provide the ability for the end host to		This protocol does not provide the ability for the end host to
	transmit a location estimate as, for example, obtained from a local		transmit a location estimate as, for example, obtained from a local
	GPS receiver, to the LIS.		GPS receiver, to the LIS.
	3.3. Response		3.3. Response
	If the client indicated a preference for location-by-reference, the		If the client indicated a preference for location-by-reference, the
	answer simply contains a URI-list, i.e., media type text/uri-list		answer simply contains a URI-list, i.e., media type text/uri-list
	[2].		[2].
	skipping to change at page 7, line 4 ¶		skipping to change at page 8, line 7 ¶
	The field value consists of one or more absolute URIs:		The field value consists of one or more absolute URIs:
	Subscribe = "Subscribe" ":" 1#absoluteURI		Subscribe = "Subscribe" ":" 1#absoluteURI
	An example is:		An example is:
	Subscribe: sip:data@example.com?Event=location		Subscribe: sip:data@example.com?Event=location
	[TBD: Since this mechanism is not limited to location delivery, this		[TBD: Since this mechanism is not limited to location delivery, this
	might be better separated into a stand-alone draft.]		might be better separated into a stand-alone draft.]
	The response containing the location information is not signed. A		The response containing the location information is not signed. A
	response containing a randomized HTTP URL is shown below.		response containing a randomized HTTP URL is shown below.
	http://example.com/15555551002adfkafjyonqoijoyukjglky		http://example.com/15555551002adfkafjyonqoijoyukjglky
	Response containing location-by-reference		Response containing location-by-reference
			3.4. Signed Location
			RELO uses XML DSIG for digitally signing location objects, as
			described in [12].
			3.5. Error Reporting
			RELO uses HTTP status codes in case of errors. In addition to the
			status code, the response SHOULD contain an entity body explaining
			the error, in a format corresponding to the Accept header field. For
			example, a device with a text-only display may allow only textual,
			rather than HTML, error explanation by listing text/plain in addition
			to the URI list and location object formats it supports. In
			addition, the HTTP Reason-Phrase SHOULD identify the error cause,
			rather than use the generic HTTP response message.
			(RELO does not define a range of protocol-specific error conditions
			since it appears highly unlikely that a client would be able to act
			on this structured information. The reason phrase and textual
			information are more likely to be useful to users and for client
			debugging, as they can represent many more error conditions.)
			3.6. Client Authentication
			For first-party requests using the IP address as a query parameter,
			authentication is OPTIONAL, but it is REQUIRED for third-party
			requests. Where necessary, RELO relies on HTTP authentication
			mechanisms, such as Digest authentication or TLS client certificates.
	4. IANA Considerations		4. IANA Considerations
	4.1. S-NAPTR Application Service Tag		4.1. S-NAPTR Application Service Tag
	This document registers the label "RELO" as the S-NAPTR application		This document registers the label "RELO" as the S-NAPTR application
	service tag according to [7] for location lookup services and defines		service tag according to [7] for location lookup services and defines
	the intended usage, interoperability considerations and security		the intended usage, interoperability considerations and security
	considerations (Section 5).		considerations (Section 5).
	4.2. HTTP Message Header 'Subscribe'		4.2. HTTP Message Header 'Subscribe'
	skipping to change at page 10, line 35 ¶		skipping to change at page 12, line 21 ¶
	[10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)		[10] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS)
	Protocol Version 1.1", RFC 4346, April 2006.		Protocol Version 1.1", RFC 4346, April 2006.
	7.2. Informative References		7.2. Informative References
	[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location		[11] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location
	Configuration Protocol; Problem Statement and Requirements",		Configuration Protocol; Problem Statement and Requirements",
	draft-tschofenig-geopriv-l7-lcp-ps-03 (work in progress),		draft-tschofenig-geopriv-l7-lcp-ps-03 (work in progress),
	October 2006.		October 2006.
			[12] Thomson, M. and J. Winterbottom, "Digital Signature Methods for
			Location Dependability",
			draft-thomson-geopriv-location-dependability-00 (work in
			progress), February 2007.
	Author's Address		Author's Address
	Henning Schulzrinne		Henning Schulzrinne
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building		450 Computer Science Building
	New York, NY 10027		New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs+geopriv@cs.columbia.edu		Email: hgs+geopriv@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The Internet Society (2006).		Copyright (C) The IETF Trust (2007).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED		THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.		WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property		Intellectual Property
	The IETF takes no position regarding the validity or scope of any		The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to		Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in		pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights		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		might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information		made any independent effort to identify any such rights. Information
End of changes. 23 change blocks.
	33 lines changed or deleted		126 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/