< draft-ietf-geopriv-deref-protocol-00.txt		draft-ietf-geopriv-deref-protocol-01.txt >
	GEOPRIV J. Winterbottom		GEOPRIV J. Winterbottom
	Internet-Draft Andrew Corporation		Internet-Draft Andrew Corporation
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: January 6, 2011 Nokia Siemens Networks		Expires: April 2, 2011 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	M. Thomson		M. Thomson
	M. Dawson		M. Dawson
	Andrew Corporation		Andrew Corporation
	July 5, 2010		September 29, 2010
	A Location Dereferencing Protocol Using HELD		A Location Dereferencing Protocol Using HELD
	draft-ietf-geopriv-deref-protocol-00		draft-ietf-geopriv-deref-protocol-01
	Abstract		Abstract
	This document describes how to use the Hypertext Transfer Protocol		This document describes how to use the Hypertext Transfer Protocol
	(HTTP) over Transport Layer Security (TLS) as a dereferencing		(HTTP) over Transport Layer Security (TLS) as a dereferencing
	protocol to resolve a reference to a Presence Information Data Format		protocol to resolve a reference to a Presence Information Data Format
	Location Object (PIDF-LO). The document assumes that a Location		Location Object (PIDF-LO). The document assumes that a Location
	Recipient possesses a secure HELD URI that can be used in conjunction		Recipient possesses a secure HELD URI that can be used in conjunction
	with the HELD protocol to request the location of the Target.		with the HELD protocol to request the location of the Target.
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on January 6, 2011.		This Internet-Draft will expire on April 2, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 22 ¶		skipping to change at page 2, line 22 ¶
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5		3. Authorization Models . . . . . . . . . . . . . . . . . . . . . 5
	3.1. Authorization by Possession . . . . . . . . . . . . . . . 6		3.1. Authorization by Possession . . . . . . . . . . . . . . . 6
	3.2. Authorization via Access Control . . . . . . . . . . . . . 7		3.2. Authorization via Access Control . . . . . . . . . . . . . 7
	3.3. Access Control with HELD Deference . . . . . . . . . . . . 7		3.3. Access Control with HELD Deference . . . . . . . . . . . . 7
	4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8		4. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 8
	4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9		4.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 9
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 9		4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 13		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	9.2. Informative references . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 15		9.2. Informative references . . . . . . . . . . . . . . . . . . 15
	Appendix B. Compliance to Location Reference Requirements . . . . 18		Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16
	B.1. Requirements for a Location Configuration Protocol . . . . 18		Appendix B. Compliance to Location Reference Requirements . . . . 19
	B.2. Requirements for a Location Dereference Protocol . . . . . 20		B.1. Requirements for a Location Configuration Protocol . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21		B.2. Requirements for a Location Dereference Protocol . . . . . 21
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22
	1. Introduction		1. Introduction
	Provision of location information by reference [RFC5808] involves the		Provision of location information by reference [RFC5808] involves the
	creation of a resource that is identified by a "location URI". A		creation of a resource that is identified by a "location URI". A
	"location URI" identifies resource that contains the location of an		"location URI" identifies resource that contains the location of an
	entity. A location URI might be a temporary resource, created in		entity. A location URI might be a temporary resource, created in
	response to a HTTP-Enabled Location Delivery (HELD)		response to a HTTP-Enabled Location Delivery (HELD)
	[I-D.ietf-geopriv-http-location-delivery] request. A location URI		[I-D.ietf-geopriv-http-location-delivery] request. A location URI
	does not intrinsically include location information, instead the URI		does not intrinsically include location information, instead the URI
	skipping to change at page 9, line 40 ¶		skipping to change at page 9, line 40 ¶
	generate a HELD error response. For instance, those defined in		generate a HELD error response. For instance, those defined in
	[I-D.ietf-geopriv-held-identity-extensions] are always invalid and		[I-D.ietf-geopriv-held-identity-extensions] are always invalid and
	can be rejected.		can be rejected.
	The LS MUST NOT generate location URIs or provide a "locationUriSet"		The LS MUST NOT generate location URIs or provide a "locationUriSet"
	in response to a dereference request. If the location request		in response to a dereference request. If the location request
	contains a "locationType" element that includes "locationURI", this		contains a "locationType" element that includes "locationURI", this
	parameter is either ignored or rejected as appropriate, based on the		parameter is either ignored or rejected as appropriate, based on the
	associated "exact" attribute.		associated "exact" attribute.
			4.2. HTTP GET Behavior
			GET is the method assumed by generic HTTP user agents, therefore
			unless context identifies an "https:" URI as a HELD URI, such a user
			agent might simply send an HTTP GET. Rather than providing an HTTP
			405 (Method Not Allowed) response indicating that POST is the only
			permitted method, this document describes a way for a LIS to provide
			a HELD location response if it receives an HTTP GET request.
			An HTTP GET request to a HELD URI produces a HELD response as if the
			following HELD request had been sent using HTTP POST:
			<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
			<locationType exact="false">
			geodetic civic
			</locationType>
			</locationRequest>
			Figure 3: GET Request Equivalent Location Request
			HTTP GET requests must be safe and idempotent [RFC2616] - that is,
			there are no side-effects of making the request. Only when a
			location URI is created does HELD request have side-effects. A
			request to a location URI can be both safe and idempotent, since a
			location URI cannot be produced in response to a request to a
			location URI.
			Note: Idempotence does not require that the same answer be provided
			to different requests only that there are no side effects.
			Changes in the response can occur for a number of reasons,
			including a change in the value of the resource: the location of
			the Target.
			Content negotiation MAY be supported to produce a presence document
			in place of a HELD location response. Where the presence document
			would otherwise be included in a "locationResponse" document, it can
			be included in the body of the HTTP response directly.
	5. Examples		5. Examples
	The example in Figure 3 shows the simplest form of dereferencing		The example in Figure 4 shows the simplest form of dereferencing
	request using HELD to the location URI		request using HELD to the location URI
	"https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that		"https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that
	this differs from the example in Section 10.1 of		this differs from the example in Section 10.1 of
	[I-D.ietf-geopriv-http-location-delivery] is in the request URI and		[I-D.ietf-geopriv-http-location-delivery] is in the request URI and
	the source of the URI.		the source of the URI.
	POST /uri/w3g61nf5n66p0 HTTP/1.1		POST /uri/w3g61nf5n66p0 HTTP/1.1
	Host: ls.example.com:49152		Host: ls.example.com:49152
	Content-Type: application/held+xml		Content-Type: application/held+xml
	Content-Length: 87		Content-Length: 87
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>		<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
	Figure 3: Minimal Dereferencing Request		Figure 4: Minimal Dereferencing Request
	Figure 4 shows the response to the previous request listing both		Figure 5 shows the response to the previous request listing both
	civic and geodetic location information of the Target's location.		civic and geodetic location information of the Target's location.
	Again, this is identical to the response in Section 10.1 of		Again, this is identical to the response in Section 10.1 of
	[I-D.ietf-geopriv-http-location-delivery] - unless policy specfies		[I-D.ietf-geopriv-http-location-delivery] - unless policy specfies
	otherwise, the Location Recipient receives the same information as		otherwise, the Location Recipient receives the same information as
	the Device.		the Device.
	HTTP/1.1 200 OK		HTTP/1.1 200 OK
	Server: Example LIS		Server: Example LIS
	Date: Tue, 10 Jan 2009 03:42:29 GMT		Date: Mon, 10 Jan 2011 03:42:29 GMT
	Expires: Tue, 10 Jan 2009 03:42:29 GMT		Expires: Tue, 11 Jan 2011 03:42:29 GMT
	Cache-control: private		Cache-control: private
	Content-Type: application/held+xml		Content-Type: application/held+xml
	Content-Length: 594		Content-Length: 676
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">		<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
	<presence xmlns="urn:ietf:params:xml:ns:pidf"		<presence xmlns="urn:ietf:params:xml:ns:pidf"
	entity="pres:3650n87934c@ls.example.com">		entity="pres:3650n87934c@ls.example.com">
	<tuple id="b650sf789nd">		<tuple id="b650sf789nd">
	<status>		<status>
	<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"		<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
	xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">		xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
	<location-info>		<location-info>
	<Point xmlns="http://www.opengis.net/gml"		<Point xmlns="http://www.opengis.net/gml"
	srsName="urn:ogc:def:crs:EPSG::4326">		srsName="urn:ogc:def:crs:EPSG::4326">
	<pos>-34.407 150.88001</pos>		<pos>-34.407 150.88001</pos>
	</Point>		</Point>
	</location-info>		</location-info>
	<usage-rules>		<usage-rules>
			<gbp:retransmission-allowed>
			false</gbp:retransmission-allowed>
	<gbp:retention-expiry>		<gbp:retention-expiry>
	2006-01-11T03:42:28+00:00</gbp:retention-expiry>		2011-01-11T03:42:29+00:00</gbp:retention-expiry>
	</usage-rules>		</usage-rules>
	<method>Wiremap</method>		<method>Wiremap</method>
	</geopriv>		</geopriv>
	</status>		</status>
	<timestamp>2006-01-10T03:42:28+00:00</timestamp>		<timestamp>2006-01-10T03:42:28+00:00</timestamp>
	</tuple>		</tuple>
	</presence>		</presence>
	</locationResponse>		</locationResponse>
	Figure 4: Response with Location Information		Figure 5: Response with Location Information
			The following GET request is treated in an equivalent fashion. The
			LS treats this request as though it were a location request of the
			form shown in Figure 3. The same response might be provided.
			GET /uri/w3g61nf5n66p0 HTTP/1.1
			Host: ls.example.com:49152
			Accept: application/held+xml
			Figure 6: GET Request
			The following GET request uses content negotiation to indicate a
			preference for a presence document.
			GET /uri/w3g61nf5n66p0 HTTP/1.1
			Host: ls.example.com:49152
			Accept: application/pidf+xml,application/held+xml;q=0.5
			Figure 7: GET Request with Content Negotiation
			The response only differs from a normal HELD location response to a
			POST request in that the "locationResponse" element is omitted and
			the "Content-Type" header reflects the changed content.
			HTTP/1.1 200 OK
			Server: Example LIS
			Date: Mon, 10 Jan 2011 03:42:29 GMT
			Expires: Tue, 11 Jan 2011 03:42:29 GMT
			Cache-control: private
			Content-Type: application/pidf+xml
			Content-Length: 591
			<?xml version="1.0"?>
			<presence xmlns="urn:ietf:params:xml:ns:pidf"
			entity="pres:3650n87934c@ls.example.com">
			... PIDF contents are identical to the previous example ...
			</presence>
			Figure 8: GET Response with PIDF-LO
	6. Security Considerations		6. Security Considerations
	Privacy of location information is the most important security		Privacy of location information is the most important security
	consideration for this document. Two measures in particular are used		consideration for this document. Two measures in particular are used
	to protect privacy: TLS and authorization policies. TLS provides a		to protect privacy: TLS and authorization policies. TLS provides a
	means of ensuring confidentiality of location information through		means of ensuring confidentiality of location information through
	encryption and mutual authentication. An authorization policy allows		encryption and mutual authentication. An authorization policy allows
	a Rule Maker to explicitly control how location information is		a Rule Maker to explicitly control how location information is
	provided to Location Recipients.		provided to Location Recipients.
	skipping to change at page 14, line 35 ¶		skipping to change at page 15, line 39 ¶
	progress), June 2010.		progress), June 2010.
	[I-D.ietf-geopriv-policy]		[I-D.ietf-geopriv-policy]
	Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
	and J. Polk, "Geolocation Policy: A Document Format for		and J. Polk, "Geolocation Policy: A Document Format for
	Expressing Privacy Preferences for Location Information",		Expressing Privacy Preferences for Location Information",
	draft-ietf-geopriv-policy-21 (work in progress),		draft-ietf-geopriv-policy-21 (work in progress),
	January 2010.		January 2010.
	[I-D.ietf-sipcore-location-conveyance]		[I-D.ietf-sipcore-location-conveyance]
	Polk, J. and B. Rosen, "Location Conveyance for the		Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	Session Initiation Protocol",		for the Session Initiation Protocol",
	draft-ietf-sipcore-location-conveyance-02 (work in		draft-ietf-sipcore-location-conveyance-03 (work in
	progress), February 2010.		progress), July 2010.
	[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	A., Peterson, J., Sparks, R., Handley, M., and E.		A., Peterson, J., Sparks, R., Handley, M., and E.
	Schooler, "SIP: Session Initiation Protocol", RFC 3261,		Schooler, "SIP: Session Initiation Protocol", RFC 3261,
	June 2002.		June 2002.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail		[RFC3851] Ramsdell, B., "Secure/Multipurpose Internet Mail
End of changes. 15 change blocks.
	28 lines changed or deleted		108 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/