draft-ietf-geopriv-deref-protocol-02.txt		draft-ietf-geopriv-deref-protocol-03.txt
	GEOPRIV J. Winterbottom		GEOPRIV J. Winterbottom
	Internet-Draft Andrew Corporation		Internet-Draft Commscope
	Intended status: Standards Track H. Tschofenig		Intended status: Standards Track H. Tschofenig
	Expires: June 19, 2011 Nokia Siemens Networks		Expires: December 25, 2011 Nokia Siemens Networks
	H. Schulzrinne		H. Schulzrinne
	Columbia University		Columbia University
	M. Thomson		M. Thomson
	M. Dawson		M. Dawson
	Andrew Corporation		Commscope
	December 16, 2010		June 23, 2011
	A Location Dereferencing Protocol Using HELD		A Location Dereferencing Protocol Using HELD
	draft-ietf-geopriv-deref-protocol-02		draft-ietf-geopriv-deref-protocol-03.txt
	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 URI that can be used in conjunction with the		Recipient possesses a URI that can be used in conjunction with the
	HELD protocol to request the location of the Target.		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 June 19, 2011.		This Internet-Draft will expire on December 25, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2011 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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 2, line 24		skipping to change at page 2, line 24
	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
	4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9		4.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 9
	5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10		5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 12		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 14		9.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	9.2. Informative references . . . . . . . . . . . . . . . . . . 14		9.2. Informative references . . . . . . . . . . . . . . . . . . 15
	Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 16		Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 17
	Appendix B. Compliance to Location Reference Requirements . . . . 19		Appendix B. Compliance to Location Reference Requirements . . . . 20
	B.1. Requirements for a Location Configuration Protocol . . . . 19		B.1. Requirements for a Location Configuration Protocol . . . . 20
	B.2. Requirements for a Location Dereference Protocol . . . . . 21		B.2. Requirements for a Location Dereference Protocol . . . . . 22
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22		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" is a URI [RFC3986] that identifies a resource		"location URI" is a URI [RFC3986] that identifies a resource
	containing the location of an entity. A location URI might identify		containing the location of an entity. A location URI can be acquired
	a temporary resource, created in response to a HTTP-Enabled Location		using a location configuration protocol, such as HTTP-Enabled
	Delivery (HELD) [RFC5985] request. A location URI does not		Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration
			Protocol (DHCP) location URI option
			[I-D.ietf-geopriv-dhcp-lbyr-uri-option]. A location URI does not
	intrinsically include location information, instead the URI is		intrinsically include location information, instead the URI is
	"dereferenced" by a Location Recipient to acquire location		"dereferenced" by a Location Recipient to acquire location
	information. This document specifies how a holder of a location URI		information. This document specifies how a holder of an "http:" or
	uses that URI to retrieve location information.		"https:" location URI uses that URI to retrieve location information.
	HELD defines a use of HTTP that enables location configuration - the		HELD defines a use of HTTP that enables location configuration - the
	process where a Device acquires location information about itself. A		process where a Device acquires location information about itself. A
	part of location configuration is the provision of a location URI.		part of location configuration is the provision of a location URI.
	However, HELD does not describe how such a URI is used; this document		However, HELD does not describe how such a URI is used; this document
	provides that definition.		provides that definition.
	This document defines how HELD is used by a Location Recipient to		This document defines how HELD is used by a Location Recipient to
	dereference a location URI and acquire location information. The		dereference a location URI and acquire location information. The
	result of this process is a location object in the form of a Presence		result of this process is a location object in the form of a Presence
	skipping to change at page 3, line 43		skipping to change at page 3, line 45
	Use of HELD as a dereferencing protocol has the advantage that the		Use of HELD as a dereferencing protocol has the advantage that the
	Location Recipient can indicate the type of location information it		Location Recipient can indicate the type of location information it
	would like to receive. This functionality is already available with		would like to receive. This functionality is already available with
	the HELD base specification, described in [RFC5985]. Furthermore,		the HELD base specification, described in [RFC5985]. Furthermore,
	the HELD response from the LIS towards the Location Recipient not		the HELD response from the LIS towards the Location Recipient not
	only provides the PIDF-LO but also encapsulates supplementary		only provides the PIDF-LO but also encapsulates supplementary
	information, such as error messages, back to the Location Recipient.		information, such as error messages, back to the Location Recipient.
	Location URIs created for use with HELD dereferencing use the		Location URIs created for use with HELD dereferencing use the
	"https:" or "http:" scheme. The behaviour described in this document		"https:" or "http:" scheme. HELD can be used by Location Recipients
	can be used by Location Recipients that are aware of the fact that		that are aware of the fact that the URI is a location URI. Mandatory
	the URI is a location URI.		support for an HTTP GET request ensures that the URI can be used even
			if it is not recognized as a location URI.
	An example scenario envisioned by this document is shown in Figure 1.		An example scenario envisioned by this document is shown in Figure 1.
	This diagram shows how a location dereference protocol fits with		This diagram shows how a location dereference protocol fits with
	location configuration and conveyance. [RFC5808] contains more		location configuration and conveyance. [RFC5808] contains more
	information on this scenario and others like it.		information on this scenario and others like it.
	+-------------+		+-------------+
	+------------+ | Location | +-----------+		+------------+ | Location | +-----------+
	| End Device | | Information | | Location |		| End Device | | Information | | Location |
	| (Target) | | Server | | Recipient |		| (Target) | | Server | | Recipient |
	+-----+------+ +------+------+ +-----+-----+		+-----+------+ +------+------+ +-----+-----+
	| | |		| | |
	.- + - - - - - - - - - - - - + -. |		.- + - - - - - - - - - - - - + -. |
	: | locationRequest | : |		: | locationRequest | : |
	. |------(location URI)---->| . |		. |------(location URI)---->| . |
	: | | : Location |		: | | : Location |
	. | locationResponse | . Configuration |		. | locationResponse | . Configuration |
	: |<-----(location URI)-----| : Protocol |		: |<-----(location URI)-----| : |
	. | | . |		. | | . |
	`- + - - - - - - - - - - - - + -' |		`- + - - - - - - - - - - - - + -' |
	| | |		| | |
	| Location Conveyance |		| Location Conveyance |
	|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|		|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
	| | |		| | |
	| .- + - - - - - - - - - - - - + -.		| .- + - - - - - - - - - - - - + -.
	| : | locationRequest | :		| : | locationRequest | :
	| . |<--------(civic)---------| .		| . |<--------(civic)---------| .
	| Dereferencing : | | :		| Dereferencing : | | :
	| Protocol . | locationResponse | .		| . | locationResponse | .
	| : |--------(PIDF-LO)------->| :		| : |--------(PIDF-LO)------->| :
	| . | | .		| . | | .
	| `- + - - - - - - - - - - - - + -'		| `- + - - - - - - - - - - - - + -'
	| | |		| | |
	Figure 1: Example of Dereference Protocol Exchange		Figure 1: Example of Dereference Protocol Exchange
	2. Terminology		2. Terminology
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	skipping to change at page 5, line 48		skipping to change at page 6, line 5
	It is important to note that this document does not mandate a		It is important to note that this document does not mandate a
	specific authorization model. It is possible to combine aspects of		specific authorization model. It is possible to combine aspects of
	both models. However, no authentication framework is provided, which		both models. However, no authentication framework is provided, which
	limits the policy options available when the "Authorization by Access		limits the policy options available when the "Authorization by Access
	Control" model is used.		Control" model is used.
	For either authorization model, the overall process is similar. The		For either authorization model, the overall process is similar. The
	following steps are followed, with minor alterations:		following steps are followed, with minor alterations:
	1. The Target acquires a location URI from the LIS. This might use		1. The Target acquires a location URI from the LIS. This uses a
	HELD as a location configuration protocol (LCP).		location configuration protocol (LCP), such as HELD or DHCP.
	2. The Target then conveys the location URI to a third party, the		2. The Target then conveys the location URI to a third party, the
	Location Recipient (for example using SIP as described in		Location Recipient (for example using SIP as described in
	[I-D.ietf-sipcore-location-conveyance]). This step is shown in		[I-D.ietf-sipcore-location-conveyance]). This step is shown in
	(2) of Figure 2.		(2) of Figure 2.
	3. The Location Recipient then needs to dereference the location URI		3. The Location Recipient then needs to dereference the location URI
	in order to obtain the Location Object (3). Depending on the URI		in order to obtain the Location Object (3). An "https:" or
	scheme of the location URI dereferencing might, as is the case		"http:" URI is dereferenced as described in this document; other
	for "https:" or "http:" URIs, be performed as described in this		URI schemes might be dereferenced using another method.
	document.
	In this final step, the Location Server (LS) or LIS makes an		In this final step, the Location Server (LS) or LIS makes an
	authorization decision. How this decision is reached depends on the		authorization decision. How this decision is reached depends on the
	authorization model.		authorization model.
	3.1. Authorization by Possession		3.1. Authorization by Possession
	In this model, possession - or knowledge - of the location URI is		In this model, possession - or knowledge - of the location URI is
	used to control access to location information. A location URI is		used to control access to location information. A location URI is
	constructed such that it is hard to guess (see C9 of [RFC5808]) and		constructed such that it is hard to guess (see C9 of [RFC5808]) and
	skipping to change at page 8, line 18		skipping to change at page 8, line 20
	that receive a particular location URI are granted location		that receive a particular location URI are granted location
	information based on the authorization policy associated with that		information based on the authorization policy associated with that
	URI.		URI.
	Providing that knowledge of a location URI is limited, policy		Providing that knowledge of a location URI is limited, policy
	appropriate to the Location Recipients that receive the location URI		appropriate to the Location Recipients that receive the location URI
	can be assigned. Selective disclosure used in this fashion can be		can be assigned. Selective disclosure used in this fashion can be
	used in place of identity-based authorization.		used in place of identity-based authorization.
	How policy is associated with a location URI is not defined by this		How policy is associated with a location URI is not defined by this
	document. [I-D.barnes-geopriv-policy-uri] describes one possible		document. [I-D.ietf-geopriv-policy-uri] describes one possible
	mechanism.		mechanism.
	Authentication of Location Recipients and use of identity-based		Authentication of Location Recipients and use of identity-based
	authorization policy is not precluded. A Location Server MAY support		authorization policy is not precluded. A Location Server MAY support
	an authentication mechanism that enables identity-based authorization		an authentication mechanism that enables identity-based authorization
	policies to be used. Future specifications might define means of		policies to be used. Future specifications might define means of
	identifying recipients.		identifying recipients.
	Note: Policy frameworks like [RFC4745] degrade in a way that		Note: Policy frameworks like [RFC4745] degrade in a way that
	protects privacy if features are not supported. If a policy		protects privacy if features are not supported. If a policy
	skipping to change at page 9, line 31		skipping to change at page 9, line 34
	The HELD "locationRequest" is the only request permitted by this		The HELD "locationRequest" is the only request permitted by this
	specification. Similarly, request parameters other than the		specification. Similarly, request parameters other than the
	following MUST NOT be accepted by the LS: "responseTime",		following MUST NOT be accepted by the LS: "responseTime",
	"locationType" (including the associated "exact" attribute).		"locationType" (including the associated "exact" attribute).
	Parameters and requests that do not have known behaviour for		Parameters and requests that do not have known behaviour for
	dereference requests MUST NOT be used. The LS MUST ignore any		dereference requests MUST NOT be used. The LS MUST ignore any
	parameters that it does not understand unless it knows the parameters		parameters that it does not understand unless it knows the parameters
	to be invalid. If parameters are understood by the LS and known to		to be invalid. If parameters are understood by the LS and known to
	be invalid, the LS MAY generate a HELD error response. For instance,		be invalid, the LS MAY generate a HELD error response. For instance,
	those defined in [I-D.ietf-geopriv-held-identity-extensions] are		those defined in [RFC6155] are always invalid and can be rejected.
	always invalid and 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		4.2. HTTP GET Behavior
	GET is the method assumed by generic HTTP user agents, therefore		GET is the method assumed by generic HTTP user agents, therefore
	unless context identifies an "https:" URI as a HELD URI, such a user		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		agent might simply send an HTTP GET. Rather than providing an HTTP
	405 (Method Not Allowed) response indicating that POST is the only		405 (Method Not Allowed) response indicating that POST is the only
	permitted method, this document describes a way for a LIS to provide		permitted method, a LIS MUST provide a HELD location response if it
	a HELD location response if it receives an HTTP GET request.		receives an HTTP GET request.
	An HTTP GET request to a HELD URI produces a HELD response as if the		An HTTP GET request to a HELD URI produces a HELD response as if the
	following HELD request had been sent using HTTP POST:		following HELD request had been sent using HTTP POST:
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">		<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
	<locationType exact="false">		<locationType exact="false">
	geodetic civic		geodetic civic
	</locationType>		</locationType>
	</locationRequest>		</locationRequest>
	Figure 3: GET Request Equivalent Location Request		Figure 3: GET Request Equivalent Location Request
	HTTP GET requests must be safe and idempotent [RFC2616] - that is,		HTTP GET requests MUST be safe and idempotent [RFC2616] - that is,
	there are no side-effects of making the request and a repeated		there are no side-effects of making the request and a repeated
	request has no more effect than a single request. Only when a		request has no more effect than a single request. Repeating a HELD
	location URI is created does HELD request have side-effects.		request might result in a different location, but only as a result of
	Repeating a HELD request might result in a different location, but		a change in the state of the resource: the location of the Target.
	only as a result of a change in the state of the resource: the
	location of the Target.
	A request to a location URI can be both safe and idempotent, since a		Only the creation of a location URI as a result of receiving a
	location URI cannot be produced in response to a request to a		request causes a HELD request to have side-effects. A request to a
	location URI.		location URI can be both safe and idempotent, since a location URI
			cannot be produced in response to a request to a location URI.
			A Location Recipient MAY infer from a response containing the HELD
			content type, "application/held+xml", that a URI references a
			resource that supports HELD.
	Content negotiation MAY be supported to produce a presence document		Content negotiation MAY be supported to produce a presence document
	in place of a HELD location response. Where the presence document		in place of a HELD location response. Where the presence document
	would otherwise be included in a "locationResponse" document, it can		would otherwise be included in a "locationResponse" document, it can
	be included in the body of the HTTP response directly by including an		be included in the body of the HTTP response directly by including an
	"Accept" header that includes "application/pidf+xml".		"Accept" header that includes "application/pidf+xml".
	5. Examples		5. Examples
	The example in Figure 4 shows the simplest form of dereferencing		The example in Figure 4 shows the simplest form of dereferencing
	skipping to change at page 12, line 39		skipping to change at page 13, line 29
	Server: Example LIS		Server: Example LIS
	Date: Mon, 10 Jan 2011 03:42:29 GMT		Date: Mon, 10 Jan 2011 03:42:29 GMT
	Expires: Tue, 11 Jan 2011 03:42:29 GMT		Expires: Tue, 11 Jan 2011 03:42:29 GMT
	Cache-control: private		Cache-control: private
	Content-Type: application/pidf+xml		Content-Type: application/pidf+xml
	Content-Length: 591		Content-Length: 591
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<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">
	... PIDF contents are identical to the previous example ...		<!-- PIDF contents are identical to the previous example -->
	</presence>		</presence>
	Figure 8: GET Response with PIDF-LO		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.
	The process by which a Rule Maker establishes an authorization policy		The process by which a Rule Maker establishes an authorization policy
	is not covered by this document; several methods are possible, for		is not covered by this document; several methods are possible, for
	instance: [I-D.barnes-geopriv-policy-uri], [RFC4825].		instance: [I-D.ietf-geopriv-policy-uri], [RFC4825].
	Use of TLS for the dereferencing of location URIs is strongly		Use of TLS for the dereferencing of location URIs is strongly
	RECOMMENDED, as discussed in Section 4. Location Recipients MUST		RECOMMENDED, as discussed in Section 4. Location Recipients MUST
	authenticate the host identity using the domain name included in the		authenticate the host identity using the domain name included in the
	location URI, using the procedure described in Section 3.1 of		location URI, using the procedure described in Section 3.1 of
	[RFC2818]. Local policy determines what a Location Recipient does if		[RFC2818]. Local policy determines what a Location Recipient does if
	authentication fails or cannot be attempted.		authentication fails or cannot be attempted.
	The authorization by possession model (Section 3.1) further relies on		The authorization by possession model (Section 3.1) further relies on
	TLS when transmitting the location URI to protect the secrecy of the		TLS when transmitting the location URI to protect the secrecy of the
	skipping to change at page 14, line 12		skipping to change at page 14, line 48
	[[IANA/RFC-EDITOR: Please remove this section before publication.]]		[[IANA/RFC-EDITOR: Please remove this section before publication.]]
	8. Acknowledgements		8. Acknowledgements
	Thanks to Barbara Stark and Guy Caron for providing early comments.		Thanks to Barbara Stark and Guy Caron for providing early comments.
	Thanks to Rohan Mahy for constructive comments on the scope and		Thanks to Rohan Mahy for constructive comments on the scope and
	format of the document. Thanks to Ted Hardie for his strawman		format of the document. Thanks to Ted Hardie for his strawman
	proposal that provided assistance with the security section of this		proposal that provided assistance with the security section of this
	document. Richard Barnes made helpful observations on the		document. Richard Barnes made helpful observations on the
	application of authorization policy.		application of authorization policy. Bernard Aboba and Julian
			Reschke contributed constructive reviews.
	The participants of the GEOPRIV interim meeting 2008 provided		The participants of the GEOPRIV interim meeting 2008 provided
	significant feedback on this document.		significant feedback on this document.
	James Polk provided input on security in June 2008.		James Polk provided input on security in June 2008.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	skipping to change at page 14, line 49		skipping to change at page 15, line 40
	[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV		[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV
	Presence Information Data Format Location Object (PIDF-LO)		Presence Information Data Format Location Object (PIDF-LO)
	Usage Clarification, Considerations, and Recommendations",		Usage Clarification, Considerations, and Recommendations",
	RFC 5491, March 2009.		RFC 5491, March 2009.
	[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",		[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)",
	RFC 5985, September 2010.		RFC 5985, September 2010.
	9.2. Informative references		9.2. Informative references
	[I-D.barnes-geopriv-policy-uri]
	Barnes, R., Thomson, M., Winterbottom, J., and H.
	Tschofenig, "Location Configuration Extensions for Policy
	Management", draft-barnes-geopriv-policy-uri-02 (work in
	progress), November 2010.
	[I-D.ietf-geopriv-arch]		[I-D.ietf-geopriv-arch]
	Barnes, R., Lepinski, M., Cooper, A., Morris, J.,		Barnes, R., Lepinski, M., Cooper, A., Morris, J.,
	Tschofenig, H., and H. Schulzrinne, "An Architecture for		Tschofenig, H., and H. Schulzrinne, "An Architecture for
	Location and Location Privacy in Internet Applications",		Location and Location Privacy in Internet Applications",
	draft-ietf-geopriv-arch-03 (work in progress),		draft-ietf-geopriv-arch-03 (work in progress),
	October 2010.		October 2010.
	[I-D.ietf-geopriv-held-identity-extensions]		[I-D.ietf-geopriv-dhcp-lbyr-uri-option]
	Winterbottom, J., Thomson, M., Tschofenig, H., and R.		Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4
	Barnes, "Use of Device Identity in HTTP-Enabled Location		and IPv6 Option for a Location Uniform Resource Identifier
	Delivery (HELD)",		(URI)", draft-ietf-geopriv-dhcp-lbyr-uri-option-11 (work
	draft-ietf-geopriv-held-identity-extensions-06 (work in		in progress), February 2011.
	progress), November 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-22 (work in progress),		draft-ietf-geopriv-policy-23 (work in progress),
	October 2010.		March 2011.
			[I-D.ietf-geopriv-policy-uri]
			Barnes, R., Thomson, M., Winterbottom, J., and H.
			Tschofenig, "Location Configuration Extensions for Policy
			Management", draft-ietf-geopriv-policy-uri-01 (work in
			progress), June 2011.
	[I-D.ietf-sipcore-location-conveyance]		[I-D.ietf-sipcore-location-conveyance]
	Polk, J., Rosen, B., and J. Peterson, "Location Conveyance		Polk, J., Rosen, B., and J. Peterson, "Location Conveyance
	for the Session Initiation Protocol",		for the Session Initiation Protocol",
	draft-ietf-sipcore-location-conveyance-04 (work in		draft-ietf-sipcore-location-conveyance-08 (work in
	progress), October 2010.		progress), May 2011.
	[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.
	[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,		[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
	skipping to change at page 16, line 16		skipping to change at page 17, line 5
	Location Configuration Protocol: Problem Statement and		Location Configuration Protocol: Problem Statement and
	Requirements", RFC 5687, March 2010.		Requirements", RFC 5687, March 2010.
	[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet		[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet
	Mail Extensions (S/MIME) Version 3.2 Message		Mail Extensions (S/MIME) Version 3.2 Message
	Specification", RFC 5751, January 2010.		Specification", RFC 5751, January 2010.
	[RFC5808] Marshall, R., "Requirements for a Location-by-Reference		[RFC5808] Marshall, R., "Requirements for a Location-by-Reference
	Mechanism", RFC 5808, May 2010.		Mechanism", RFC 5808, May 2010.
			[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R.
			Barnes, "Use of Device Identity in HTTP-Enabled Location
			Delivery (HELD)", RFC 6155, March 2011.
	Appendix A. GEOPRIV Using Protocol Compliance		Appendix A. GEOPRIV Using Protocol Compliance
	This section describes how use of HELD as a location dereference		This section describes how use of HELD as a location dereference
	protocol complies with the GEOPRIV requirements described in		protocol complies with the GEOPRIV requirements described in
	[RFC3693].		[RFC3693].
	Req. 1. (Location Object generalities):		Req. 1. (Location Object generalities):
	This section relates to the PIDF-LO [RFC4119] document,		This section relates to the PIDF-LO [RFC4119] document,
	which is used by HELD. These requirements are addressed by		which is used by HELD. These requirements are addressed by
	skipping to change at page 19, line 42		skipping to change at page 20, line 32
	C1. "Location URI support: The location configuration protocol MUST		C1. "Location URI support: The location configuration protocol MUST
	support a location reference in URI form."		support a location reference in URI form."
	Compliant: HELD only provides location references in URI form.		Compliant: HELD only provides location references in URI form.
	C2. "Location URI expiration: When a location URI has a limited		C2. "Location URI expiration: When a location URI has a limited
	validity interval, its lifetime MUST be indicated."		validity interval, its lifetime MUST be indicated."
	Compliant: HELD indicates the expiry time of location URIs using		Compliant: HELD indicates the expiry time of location URIs using
	the "expires" attribute. [I-D.barnes-geopriv-policy-uri]		the "expires" attribute. [I-D.ietf-geopriv-policy-uri] provides
	provides a way to control expiration of a location URI; a Device		a way to control expiration of a location URI; a Device is able
	is able to specify limits on the life time of a HELD context.		to specify limits on the life time of a HELD context.
	C3. "Location URI cancellation: The location configuration protocol		C3. "Location URI cancellation: The location configuration protocol
	MUST support the ability to request a cancellation of a specific		MUST support the ability to request a cancellation of a specific
	location URI."		location URI."
	Compliant with Extension: [I-D.barnes-geopriv-policy-uri]		Compliant with Extension: [I-D.ietf-geopriv-policy-uri]
	describes how a location URI can be cancelled through the		describes how a location URI can be cancelled through the
	application of policy. Without extensions, HELD does not		application of policy. Without extensions, HELD does not
	provide a method for cancelling location URIs.		provide a method for cancelling location URIs.
	C4. "Location Information Masking: The location URI MUST ensure, by		C4. "Location Information Masking: The location URI MUST ensure, by
	default, through randomization and uniqueness, that the location		default, through randomization and uniqueness, that the location
	URI does not contain location information specific components."		URI does not contain location information specific components."
	Compliant: The HELD specification explicitly references this		Compliant: The HELD specification explicitly references this
	requirement in providing guidance on the format of the location		requirement in providing guidance on the format of the location
	skipping to change at page 20, line 36		skipping to change at page 21, line 26
	Not Compliant: Specific extensions to the protocol or		Not Compliant: Specific extensions to the protocol or
	authorization policy formats is needed to alter the default		authorization policy formats is needed to alter the default
	behavior, which allows unlimited resolution of the location URI.		behavior, which allows unlimited resolution of the location URI.
	C7. "Selective disclosure: The location configuration protocol MUST		C7. "Selective disclosure: The location configuration protocol MUST
	provide a mechanism that allows the Rule Maker to control what		provide a mechanism that allows the Rule Maker to control what
	information is being disclosed about the Target."		information is being disclosed about the Target."
	Compliant with Extension: Use of policy mechanisms and		Compliant with Extension: Use of policy mechanisms and
	[I-D.barnes-geopriv-policy-uri] enable this capability. Note		[I-D.ietf-geopriv-policy-uri] enable this capability. Note that
	that this document recommends that only location information be		this document recommends that only location information be
	provided.		provided.
	C8. "Location URI Not guessable: As a default, the location		C8. "Location URI Not guessable: As a default, the location
	configuration protocol MUST return location URIs that are random		configuration protocol MUST return location URIs that are random
	and unique throughout the indicated lifetime. A location URI		and unique throughout the indicated lifetime. A location URI
	with 128-bits of randomness is RECOMMENDED."		with 128-bits of randomness is RECOMMENDED."
	Compliant: HELD specifies that location URIs conform to this		Compliant: HELD specifies that location URIs conform to this
	requirement.		requirement.
	skipping to change at page 22, line 8		skipping to change at page 23, line 8
	the location server."		the location server."
	Compliant: This document strongly recommends the use of TLS for		Compliant: This document strongly recommends the use of TLS for
	confidentiality and HELD mandates its implementation. Unsecured		confidentiality and HELD mandates its implementation. Unsecured
	HTTP is permitted: the associated risks are described in		HTTP is permitted: the associated risks are described in
	Section 4.		Section 4.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	Andrew Corporation		Commscope
	Andrew Building (39)		Andrew Building (39)
	Wollongong University Campus		Wollongong University Campus
	Northfields Avenue		Northfields Avenue
	Wollongong, NSW 2522		Wollongong, NSW 2522
	AU		AU
	Phone: +61 242 212938		Phone: +61 242 212938
	Email: james.winterbottom@andrew.com		Email: james.winterbottom@commscope.com
	Hannes Tschofenig		Hannes Tschofenig
	Nokia Siemens Networks		Nokia Siemens Networks
	Linnoitustie 6		Linnoitustie 6
	Espoo 02600		Espoo 02600
	Finland		Finland
	Phone: +358 (50) 4871445		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@gmx.net		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.priv.at		URI: http://www.tschofenig.priv.at
	skipping to change at page 22, line 39		skipping to change at page 23, line 39
	Columbia University		Columbia University
	Department of Computer Science		Department of Computer Science
	450 Computer Science Building, New York, NY 10027		450 Computer Science Building, New York, NY 10027
	US		US
	Phone: +1 212 939 7004		Phone: +1 212 939 7004
	Email: hgs@cs.columbia.edu		Email: hgs@cs.columbia.edu
	URI: http://www.cs.columbia.edu		URI: http://www.cs.columbia.edu
	Martin Thomson		Martin Thomson
	Andrew Corporation		Commscope
	Andrew Building (39)		Andrew Building (39)
	Wollongong University Campus		Wollongong University Campus
	Northfields Avenue		Northfields Avenue
	Wollongong, NSW 2522		Wollongong, NSW 2522
	AU		AU
	Phone: +61 2 4221 2915		Phone: +61 2 4221 2915
	Email: martin.thomson@andrew.com		Email: martin.thomson@commscope.com
	Martin Dawson		Martin Dawson
	Andrew Corporation		Commscope
	Andrew Building (39)		Andrew Building (39)
	Wollongong University Campus		Wollongong University Campus
	Northfields Avenue		Northfields Avenue
	Wollongong, NSW 2522		Wollongong, NSW 2522
	AU		AU
	Phone: +61 2 4221 2992		Phone: +61 2 4221 2992
	Email: martin.dawson@andrew.com		Email: martin.dawson@commscope.com
End of changes. 38 change blocks.
	76 lines changed or deleted		84 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/