< draft-winterbottom-geopriv-held-context-03.txt		draft-winterbottom-geopriv-held-context-04.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: April 2, 2009 Nokia Siemens Networks		Expires: October 16, 2009 Nokia Siemens Networks
	M. Thomson		M. Thomson
	Andrew Corporation		Andrew Corporation
	September 29, 2008		April 14, 2009
	HELD Protocol Context Management Extensions		Establishing Location URI Contexts using HTTP-Enabled Location Delivery
	draft-winterbottom-geopriv-held-context-03.txt		(HELD)
			draft-winterbottom-geopriv-held-context-04
	Status of this Memo		Status of This Memo
	By submitting this Internet-Draft, each author represents that any		This Internet-Draft is submitted to IETF in full conformance with the
	applicable patent or other IPR claims of which he or she is aware		provisions of BCP 78 and BCP 79.
	have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		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.
	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."
	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 April 2, 2009.		This Internet-Draft will expire on October 16, 2009.
			Copyright Notice
			Copyright (c) 2009 IETF Trust and the persons identified as the
			document authors. All rights reserved.
			This document is subject to BCP 78 and the IETF Trust's Legal
			Provisions Relating to IETF Documents in effect on the date of
			publication of this document (http://trustee.ietf.org/license-info).
			Please review these documents carefully, as they describe your rights
			and restrictions with respect to this document.
	Abstract		Abstract
	This document describes a protocol extension for the HTTP Enabled		This document describes a protocol extension for the HTTP-Enabled
	Location Delivery (HELD) protocol. It allows a Target to manage		Location Delivery (HELD) protocol. It allows a Target to manage
	their location information on a Location Information Server (LIS)		their location information on a Location Information Server (LIS)
	through the application of constraints invoked by accessing a		through the application of constraints invoked by accessing a
	location URI. Constraints described in this memo restrict how often		location URI. Constraints described in this memo restrict how often
	location can be accessed through a location URI, how long the URI is		location can be accessed through a location URI, how long the URI is
	valid for, and the type of location information returned when a		valid for, and the type of location information returned when a
	location URI is accessed. Extension points are also provided.		location URI is accessed. Extension points are also provided.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5		3. HELD Contexts . . . . . . . . . . . . . . . . . . . . . . . . 4
	4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6		3.1. Simplified Model . . . . . . . . . . . . . . . . . . . . . 4
	4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6		3.2. Authorization Policies . . . . . . . . . . . . . . . . . . 5
	4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7		3.3. Context Lifetime . . . . . . . . . . . . . . . . . . . . . 6
	5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8		3.4. Snapshot Contexts . . . . . . . . . . . . . . . . . . . . 6
	5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8		4. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 6
	5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9		4.1. Create Context . . . . . . . . . . . . . . . . . . . . . . 7
	5.3. Context Response Message . . . . . . . . . . . . . . . . . 10		4.2. Update Context . . . . . . . . . . . . . . . . . . . . . . 8
	5.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11		4.3. Context Response Message . . . . . . . . . . . . . . . . . 10
	5.5. Location URI and Context Identifier Generation Rules . . . 12		4.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11
	6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 13		4.5. Location URI and Context Identifier Generation Rules . . . 12
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 12
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	8.1. URN Sub-Namespace Registration for		6.1. Multiple Contexts from the 'Same' Target . . . . . . . . . 16
	urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 18		7.1. URN Sub-Namespace Registration for
	8.3. New HELD Error Code Registration . . . . . . . . . . . . . 19		urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 17
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20		7.2. XML Schema Registration . . . . . . . . . . . . . . . . . 17
	Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 21		7.3. HELD Error Code Registration . . . . . . . . . . . . . . . 18
	Appendix B. HELD Compliance to IETF Location Configuration		8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
	Protocol Location Reference Requirements . . . . . . 23		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 25		9.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26		9.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Intellectual Property and Copyright Statements . . . . . . . . . . 27		Appendix A. Compliance to Location by Reference Requirements . . 20
	1. Introduction		1. Introduction
	The HTTP Enabled Location Delivery (HELD) protocol specification		The HTTP Enabled Location Delivery (HELD) protocol specification
	[I-D.ietf-geopriv-http-location-delivery] provides a set of features		[I-D.ietf-geopriv-http-location-delivery] provides a set of features
	that can be used by a Target to retrieve location information from a		that can be used by a Target to retrieve location information from a
	Location Information Server (LIS). The basic HELD specification does		Location Information Server (LIS). The LIS is able to optionally
	this in a more or less stateless manner, and when a location URI is		provide a location URI [I-D.ietf-geopriv-lbyr-requirements], which
	retrieved the Target has no way of controlling how the URI is used; a		provides a reference to location information.
	Location Recipient in pocession of the location URI can get the
	Target's location until the URI expires. This basic mechanism may be		A location URI that is provided by a LIS using the basic HELD
	reasonable in a limited set of applications, but is unacceptable in a		specification, is essentially immutable once retrieved. There is no
	broader range of applications. This position is highlighted in		means provided of controlling how the URI is used. A default policy
	[I-D.ietf-geopriv-lbyr-requirements] which describes requirements for		is applied to the URI, which is fixed until the location URI expires;
	constraints relating to location URIs. This specification provides		a Location Recipient in possession of the location URI can retrieve
	support for these requirements in HELD.		the Target's location until the expiry time lapses.
			This basic mechanism may be reasonable in a limited set of
			applications, but is unacceptable in a broader range of applications.
			In particular, the ability to change policy dynamically is required
			to better protect the privacy of the Target.
			[I-D.ietf-geopriv-lbyr-requirements] enumerates several requirements
			relating to location URIs that cannot be achieved using the basic
			HELD specification. This specification provides support for these
			requirements in HELD.
			Two new forms of HELD request are defined by this document. These
			requests relate to the creation and maintenance of a _HELD context_,
			a concept that is explained in more detail in Section 3.
	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 [RFC2119].		document are to be interpreted as described in [RFC2119].
	This document reuses the terms Target, as defined in [RFC3693].		This document uses the terms defined in [RFC3693] (Target, Location
			Recipient, Location Server), [I-D.ietf-geopriv-lbyr-requirements]
			(location URI), and [I-D.ietf-geopriv-l7-lcp-ps] (Location
			Information Server, or LIS).
	This document uses the term Location Information Server (LIS) as the		The distinction between Location Server (LS) and Location Information
	node in the access network that provides location information about a		Server (LIS) is important. LS is used to refer to the role that
	Target. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps].		serves a location URI, whereas a LIS is the role that provides the
			location configuration. Both roles might be assumed by the same
			entity, but the roles could be separate.
	3. What is a Context?		3. HELD Contexts
	A Location URI points to a LIS that is able to provide the location		A location URI is a reference to the current location of a Target.
	of a specific Target. The LIS is able to map the URI to the location		The host identified in the URI, the Location Server (LS), serves
	of the Target inside its administrative domain. We call this mapping		requests to a location URI using two classes of data:
	a "context". In the basic HELD specification the context is
	implicitly created with the request for a location URI in the
	locationRequest message. The Target has no control of the mapping
	from the URI to the Target's location. This specification provides a
	degree of control to the Target, allowing it to specify rules to the
	LIS on how a context should map a URI to location information.
	A context expires when it reaches a certain age, at which time the		authorization policy: Authorization policies are set by Rule Makers
	mapping between the URI and the Target's location ceases. In the		and determine whether the requester is permitted to receive
	basic HELD specification the exiry time of the context is determined		location information and whether there are any constraints on that
	by the LIS when the Target requests a location URI. By allowing the		information.
	Target to specify and change the life time of a context the Target is
	able to create URIs for limited periods, or to terminate URIs for
	which it no longer wishes its location to be returned. This
	specification provides explicit support for this functionality.
	4. Constraints		location determination inputs: Information on the identity of the
			Target and how location information for that Target can be
			acquired might be saved by the LS.
	Constraints restrict the ability of a Location Recipient to resolve a		This information is associated with every location URI served by an
	location URI to location information. The constraints are selected		LS. The collection of data used by the LS establishes a "context"
	by the Target and they are provided to the LIS that maintains them		for the location dereference request made by a Location Recipient.
	along with the context. A LIS, understanding this specification,
	receives constraints provided by the Target, and returns a set of
	URIs influenced by the constraints.
	A single Target may want to place different contraints on different		In HELD [I-D.ietf-geopriv-http-location-delivery], the establishment
	references and hence may have multiple contexts on the LIS. The		of the necessary contextual information is implicit. Creation of a
	constraints describe what actions the LIS MUST take when a URI		location URI implies that the LIS has provided the LS with sufficient
	associated with the context is accessed. This document describes two		information to service requests to that URI.
	basic constraints that a Target can use in combination for the same
	context. Once set, these rules remain in force of the life of the
	context.
	4.1. Limited Use URIs		This document provides a more explicit mechanism for the creation and
			management of the contextual information used in serving a location
			URI. This information - dubbed a "HELD context" (simply "context" in
			this document) - can be created, updated and destroyed at the request
			of the Device. In addition, a Device is able to establish
			authorization policies in the form of common policy documents
			[RFC4745] that provide greater control over how a location URI is
			served by the LS.
	A limited use URI can only be accessed a fixed number of times to		3.1. Simplified Model
	yield the location of the Target. Each time the URI is used to
	provide the location of the Target one usage is consumed. Once the
	limit is reached the URI no longer yields the location of the Target
	and the URI is deemed spent.
	By setting the usage limit to 1, the Target is able to create a one-		The model assumed in this specification, shown in Figure 1, is a
	time-URI permitting a Location Recipient to obtain the Target's		simplified variant of that in [RFC3693] that includes the LIS entity.
	location only once. Setting the usage limit to something higher than
	1 creates functionality analogous to a metro-ticket, where a Location
	Recipient in possession of the URI can access the Target's location
	many more times, but not exceeding the imposed limit.
	Not setting a usage limit provides similar semantics to the URI in		+------------+
	the base HELD specification, enabling a Location Recipient to		| |
	continually obtain the Target's location until the URI expires due to		| Rule Maker | +-------------+ +-----------+
	age.		| | | | | |
			+ - - -- - - + | Location | | Location |
			| | | Server |-----------| Recipient |
			| Target | | | (LDP) | |
			| | + - - - - - - + +-----------+
			+ - - -- - - + | | |
			| | | Location | |
			| Device |-----------| Information | |
			| | (LCP) | Server | |
			+------------+ | | |
			| +-------------+ |
			| |
			`------------------(Conveyance)-------------------'
	When a HELD URI is assigned to a context, the limit is the number of		Figure 1: HELD Contexts Model
	times that the URI can be accessed before the LIS returns an error.
	In the case of SIP or pres URIs it is the number of NOTIFY messages
	that are sent prior to the LIS returning an error. Where a context
	supports SIP, pres, and HELD URIs it is the combination of URI
	accesses and NOTIFY messages that constitutes the usage value, each
	time the Target's location is provided constitutes a usage.
	4.2. Snapshot URIs		This model assumes some form of relationship between a Rule Maker,
			Target and Device; for instance, the Rule Maker and Target might be
			the same person. The Device is operated under the control of a Rule
			Maker and is able to provide authorization policies or disseminate
			location URIs in accordance with the Rule Maker's wishes.
	A snapshot URI points to the location of the Target at a specific		This document also assumes a relationship is assumed between LIS and
	point in time, and no matter how many times the URI is accessed it		LS. LIS and LS together generate location URIs and maintain context
	will always yield the same location. This is useful if, for example,		information. These roles could be filled by the same entity.
	the Target does not want to be tracked. In this specification the
	location snapshot to which a snapshot URIs points is captured when
	the context is created on the LIS.
	5. Protocol Details		The location configuration protocol (LCP) interface is extended by
			this document to include a rules interface for the Rule Maker
			associated with the Target and Device. This model does not preclude
			the existence of other Rule Makers that use other rules interfaces.
			3.2. Authorization Policies
			A Device is able to specify an authorization policy when creating or
			updating a context. The authorization policy states which Location
			Recipients are able to access location information through the
			context and the associated URIs, plus any other constraints on this
			access.
			A Device is able to provide a policy document in the form of a common
			policy document [RFC4745] or an "https:" reference to one. Existence
			of an explicit authorization policy implies that the "authorization
			by access control lists" model ([I-D.ietf-geopriv-lbyr-requirements])
			is to be applied. The LS uses the authorization policy document to
			control how location information is provided to Location Recipients.
			Absence of policy, or an explicit indication otherwise, indicates
			that the LS is permitted to apply the "authorization by possession"
			model ([I-D.ietf-geopriv-lbyr-requirements]). Any Location Recipient
			that proves possession of the location URI by making a location
			dereference request to the URI is granted permission to receive the
			location information. Location URIs for the associated context have
			random components with enough entropy to make possession more likely
			to be as a result of receiving the location URI from the Device than
			guesswork.
			3.3. Context Lifetime
			A HELD context has a finite lifetime. This limits the time that a
			context might refer to a Device that has since left the network. Of
			course, a LIS might have a means of detecting the absence of a given
			Device, invaliding any contexts when the Device is no longer present.
			The lifetime of the context is negotiated between Device and LIS.
			The Device requests a certain lifetime and the LIS provides a
			location URI that is valid for up to the requested time. A Device is
			able to extend the lifetime of a context by updating the context
			information. Given regular updates, a context might persist
			indefinitely, providing that authorization by possession is not used.
			A Device can request that the LIS remove context information,
			invalidating the associated location URIs, by the same mechanism used
			to extend the lifetime.
			3.4. Snapshot Contexts
			At the time that a context is created, the Device is able to request
			that the context refer to a static document that is created at the
			time of request. The LIS creates a Location Object (LO) based on the
			associated HELD request parameters and stores the LO. All requests
			to the location URI created in response to this request are served
			based on the stored LO.
			This basic constraint on the context applies for the life of the
			context. Only the application of authorization policy rules can
			change what is provided to different Location Recipients. If
			authorization by possession is used, the associated location URI is
			different to a Location Object only in that it needs to be
			dereferenced.
			4. Protocol Details
	This specification introduces three new HELD messages, create context		This specification introduces three new HELD messages, create context
	(<createContext>), update context (<updateContext>), and context		(<createContext>), update context (<updateContext>), and context
	response (<contextResponse>). A LIS that does not understand this		response (<contextResponse>).
	specification is expected to return a HELD _unsupportedMessage_ error
	code in a HELD error message. A LIS that does understand this
	specification returns errors associated with context operations in a
	HELD error message. New error codes relating to failed context
	operations are defined in this specification.
	The specification assumes that the LIS was discovered as part of the		All context-related messages are HELD messages, sent using the
	general HELD LIS discovery process. All messages are sent using the		"application/held+xml" MIME type defined in
	application/held+xml MIME type as defined in
	[I-D.ietf-geopriv-http-location-delivery].		[I-D.ietf-geopriv-http-location-delivery].
	5.1. Create Context Message		A LIS that does not understand this specification returns a HELD
			"unsupportedMessage" error code in a HELD "error" message. A LIS
	The Target creates a context on the LIS using a create context		that does understand this specification returns errors associated
	message. The basic create context message supports the constraints		with context operations in a HELD error message. New error codes
	described in Section 4 and consist of two attributes and one element		relating to failed context operations are defined in Section 4.4.
	described below:
	o "uses": an optional attribute instructing the LIS on how many		The specification assumes that the LIS was discovered as part of the
	times a URI may yield the location of the Target. This is a		LIS discovery [I-D.ietf-geopriv-lis-discovery] and that the LIS is
	positive integer, and has a default value of _unlimited_. The LIS		able to provide location information.
	SHOULD support the Target specifying up to at least 100 uses.
	o "snapshot": an optional attribute instructing the LIS to take a		4.1. Create Context
	snapshot of the Target's location for use with the context. This
	a boolean value and has a default of _false_ meaning that a
	snapshot is not taken, and the Target's location is determined
	each time the URI is accessed.
	o "lifeTime": is a mandatory element that defines the maximum period		The Device creates a context on the LIS using a create context
	in seconds that the LIS should keep the context for. The LIS MAY		message. A sample create context request is shown in Figure 2.
	create the context with a shorter life time than was requested,
	but the life time MUST NOT be longer than was requested.
	<createContext		<createContext
	xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
	uses="10"		<lifetime>7200</lifetime>
	snapshot="false">		<snapshot>false</snapshot>
	<lifeTime>7200</lifeTime>		<policy>
			<ruleset-reference>
			http://policy.example.com/geolocation-policy/users/alice/index
			</ruleset-reference>
			</policy>
	</createContext>		</createContext>
	Figure 1: createContext Example		Figure 2: Create Context Example
	Figure 1 shows a create context message defining a context which:		The following parameters of the create context request are defined:
	o may be accessed 10 times		lifetime: The maximum lifetime of the context in seconds. All
			create contexts requests include this parameter. The LIS MAY
			create the context with a shorter lifetime than was requested, but
			the lifetime MUST NOT be longer than was requested.
	o will determine the location of the Target each time it is accessed		snapshot: Whether the value provided to location Recipients is fixed
			from the time that the context is created (see Section 3.4). This
			a boolean parameter with a default value of "false", meaning that
			the context the Target's location at the time that the location
			URI is dereferenced.
	o will be valid for 2 hours from the time of context creation		policy: An authorization policy, either included directly as an
			instance of a common policy [RFC4745] document, or by reference as
			a URI. Only one of the following forms of policy are permitted:
	5.2. Update Context Message		cp:ruleset: The Device is able to provide an authorization policy
			explicitly in the request by including a common policy document
			in the create context request. A "ruleset" element is included
			as a child of the "policy" element.
	A Target can change the life time of a context using an update		ruleset-reference: Alternatively, a reference to a policy
	context message. As stated in Section 4 the two attributes used in		document can be included using the "ruleset-reference" element.
	the context creation, "uses" and "snapshot" cannot be changed once a		A Rule Maker might maintain an authorization policy on a server
	context is created.		(perhaps with XCAP [RFC4825]). This reference MUST be an
			"https:" URI. The LS MUST retrieve the policy before granting
			any Location Recipient access to location information; the
			policy MAY either be retrieved immediately or as a Location
			Recipient makes a request. The LS can be expected to retrieve
			the policy document once only, but it MAY be retrieved multiple
			times.
	Since the Target may have more than one context on the LIS, the		Note that the LIS could be unable to detect errors in policy
	Target needs to identify the context to be updated. It does this by		before sending a response to a request that includes this
	including a context identifier that is provided to it by the LIS when		element. A successful context response might be sent, even if
	the context is created.		the policy document cannot be retrieved by the LIS or the
			referenced policy document is not understood by the LIS.
			possession: Absence of policy information in a create context
			request implies that authorization by possession
			[I-D.ietf-geopriv-lbyr-requirements] is used for the context.
			The "possession" element provides an explicit indication that
			this policy is to be applied.
			otherPolicy: Alternative policy information might be provided.
			This element is provided to allow for expansion. A LIS MAY
			reject requests that contain policy that it does not understand
			with the "badPolicy" error code.
			4.2. Update Context
			A Device is able to update policy or change the lifetime of a context
			using an update context request. Other context parameters defined in
			other specification might also be updated using this method.
			Once created, a context that contains a "snapshot" of the Target's
			location cannot be made dynamic; the same applies in converse, a
			dynamic context cannot be made into a static snapshot.
			A Device might maintain more than one HELD context; therefore, the
			request needs to identify the context to be updated. The
			"context-id" is included in this message.
	<updateContext		<updateContext
	xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
	id="uhvuhdbnuiehudbnvcujevuijeijcvij3">		<context-id>uhvuhdbnuiehudbnvcujevuijeijcvij3</context-id>
	<lifeTime>3600</lifeTime>		<lifetime>3600</lifetime>
			<policy>
			<cp:ruleset xmlns:cp="urn:ietf:params:xml:ns:common-policy">
			<!-- authorization policy rules -->
			</cp:ruleset>
			</policy>
	</updateContext>		</updateContext>
	Figure 2: updateContext Life Time Change Example		Figure 3: Update Context Example
	When a Target includes a life time element in an update context		When a Device includes a "lifetime" element in an update context
	message, the LIS needs to calculate a new context expiry time. The		message, the lifetime of the context is modified. If the requested
	LIS MUST do this by adding the new life time value to the current		lifetime is longer than the time remaining before the context
	time on the LIS. This mechanism means the Target can terminate a		expires, the context lifetime is lengthened. If the requested
	context at any time. It does this by updating the context with a		lifetime is shorter than the remaining time, the context lifetime is
	life time of 0, which results in the LIS setting the context expiry		shortened.
	time to the present. The LIS MAY also terminate a context if the
	life time value is set to less than 10 seconds.		A context that is updated continuously can be maintained indefinitely
			using this mechanism. The LIS MAY provide a shorter lifetime than
			the requested time. In particular, the total lifetime of contexts
			that use authorization by possession MUST be limited.
			This mechanism also allows for the cancellation of contexts. The
			Device indicates a context lifetime of 0 in the update context
			request. The LIS MAY also terminate a context immediately if the
			lifetime value is less than 10 seconds.
	<updateContext		<updateContext
	xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
	id="uhvuhdbnuiehudbnvcujevuijeijcvij3">		<context-id>uhvuhdbnuiehudbnvcujevuijeijcvij3</context-id>
	<lifeTime>0</lifeTime>		<lifetime>0</lifetime>
			<policy>
			<possession/>
			</policy>
	</updateContext>		</updateContext>
	Figure 3: updateContext Termination Example		Figure 4: Update Context Termination Example
	5.3. Context Response Message		When an update context request contains policy information, that
			policy information replaces any existing policy. Omitting the
			"policy" element means that the previous policy remains unchanged.
			If a "ruleset-reference" element is provided, the LS MUST retrieve
			the referenced policy document before serving subsequent requests
			from Location Recipients. Conditional HTTP requests, such as those
			containing the "If-Modified-Since" header MAY be used to avoid
			retrieval of the entire policy.
	The LIS informs the Target about the outcome of context operations		The rules regarding the construction of location URIs in
	through the context response message. The LIS MUST always send a		[I-D.ietf-geopriv-lbyr-requirements] differ based on the
	context response message to a Target in response to a create context		authorization model used. The LIS MUST NOT permit a change in policy
	or update context message when the outcome was successful. The		if the location URIs associated with the context do not meet the
	context response message contains a "code" attribute indicating the		requirements for the updated authorization model. See Section 4.5
	performed operation, and the other attributes and elements indicating		for more details.
	the state of the context.
	The "code" attribute is an enumerated type and has one of the		4.3. Context Response Message
	following values:
	o _created_: The context was successfully created.		The context response message is sent in response to a create context
			request or an update context request. This message includes
			information about the context that has been created, updated or
			destroyed.
	o _destroyed_: The context was destroyed.		The "code" attribute of the context response indicates what action
			was accomplished by the request:
	o _updated_: The context was successfully updated.		created: The context was successfully created.
	The following list details the other attributes that may be returned		updated: The context was successfully updated.
	in a context response message.
	id: The identifier allocated to the context by the LIS. This		destroyed: The context was destroyed.
	identifier is unique in the scope of the LIS. The Target MUST
	keep this secret and MUST included it in all update requests. The
	LIS MUST return an "id" in all context response messages.
	uses: The number of times that the context will yield the Target's		The context response contains a "context" element that includes
	location. The LIS MAY report either the original value, or the		information about the context that was the subject of the request.
	number of remaining uses. The LIS MUST report this value for all
	responses pertaining to a known and valid context. This value MAY
	be ommitted when indicating that a context has been destroyed.
	snapshot: The value of the snapshot attribute in the context. The		id: A value that uniquely identifies the context within the context
	LIS MUST report this value for all responses pertaining to a known		of the LIS. This identifier is used to identify a context for
	and valid context. This value MAY be ommitted when indicating		update context requests. Knowledge of this value is used by the
	that a context has been destroyed.		LIS to authenticate and authorize update context requests. The
			Target MUST keep this value secret.
	expiry: The time at which the context will expire. After this time,		expires: The time at which the context will expire. After this
	all location URIs that reference this context no longer work. The		time, all location URIs that reference this context no longer
	LIS MUST report this value for all responses pertaining to a known		work.
	context. This attribute MUST be provided even when a "code" value
	of _destroyed_ is included in the context repsonse message.
	In addition to the above attributes, the LIS also provides a set of		snapshot: Whether the context contains a snapshot of the Target's
	URIs that can used to access the Target's location with the surety		location. This value has a default value of "false".
	that the context constraints will be applied. A URI set is returned
	whenever a context is successfully created on the LIS, and this set
	remains unchanged for the lifetime of the context. A context
	response message sent in reply to the create context message in
	Figure 1 might look like Figure 4.
	<contextResponse		The LIS also provides a set of URIs that can used to access the
	xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		Target's location using the created context. The set of URIs does
	code="created"		not change over the lifetime of the context.
	id="uhvuhdbnuiehudbnvcujevuijeijcvij4"
	uses="10"		A context response message sent in reply to the create context
	snapshot="false"		message in Figure 2 might look like Figure 5.
	expires="2007-11-01T13:30:00">
			<contextResponse code="created"
			xmlns="urn:ietf:params:xml:ns:geopriv:held:context">
			<context id="uhvuhdbnuiehudbnvcujevuijeijcvij4"
			snapshot="false" expires="2007-11-01T13:30:00">
	<locationUriSet>		<locationUriSet>
	<locationURI>		<locationURI>
	held://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4		https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4
	</locationURI>		</locationURI>
	<locationURI>		<locationURI>
	sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769		pres:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769
	</locationURI>		</locationURI>
	</locationUriSet>		</locationUriSet>
			</context>
	</contextResponse>		</contextResponse>
	Figure 4: contextResponse Example		Figure 5: Context Response Example
	5.4. Context Errors		4.4. Context Errors
	When the LIS is unable to perform the requested context operation it		A set of new HELD error codes are minted for use in context requests
	need to inform the Target of this. It does this using a held error		and responses:
	message. New codes are defined for context operation errors:
	o _badContextMessage_: The LIS was unable to understand the content		badPolicy: The LIS (or LS) was unable to use the included policy due
	of the message. In general this will apply to context messages		to it being invalid, badly formed, or inaccessible (when
	containing extensions that the LIS does not understand.		"ruleset-reference" is used). A LIS MAY return an error with this
			code if the policy contains no rules that could be used under any
			circumstances. For instance, all the rules might have validity
			intervals that do not correspond with the lifetime of the URI, or
			rules might require authentication modes that are not supported by
			the LS.
	o _unknownContext_: The LIS was unable to find the context.		unknownContext: The LIS was unable to find the context, possibly
			because the context identifier provided was invalid or because the
			context has already expired.
	o _updateContextFailed_: The LIS was unable to updated the requested		contextFailure: The LIS was unable to create or update the context.
	context.
	o _createContextFailed_: The LIS was unable to created the requested		Any other HELD error message can be provided in response to a create
	context.		or update context request.
	A Target implementing this specification MUST accept a any HELD error		The following HELD error is sent in response to a create context
	message as a valid response to a create context or update context		request where the LIS indicates that snapshot is not supported.
	message as a LIS may not understand context messages. A LIS that
	does understand context messages is expected to return the error
	codes above under the prescribed circumstances.
	<error xmlns="urn:ietf:params:xml:ns:geopriv:held"		<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
	code="createContextFailed"		code="contextFailure" message="Snapshot is not supported"/>
	message="Snapshot is not supported"/>
	Figure 5: Example Error Message		Figure 6: Example Error Message
	5.5. Location URI and Context Identifier Generation Rules		4.5. Location URI and Context Identifier Generation Rules
	A primary aim of this specification is to provide a Target a means to		Location URIs generated by a LIS (or LS) MUST meet the construction
	cancel a location URI so that it can no longer be used to provide its		requirements in [I-D.ietf-geopriv-lbyr-requirements]. In particular,
	location. To achieve this, a location URI generated as part of a		the requirements for a location URI that operates on the
	context creation needs to be unique with in the scope of the LIS, and		authorization by possession model are more stringent than one that
	identify only that context. If the Target destroys a context and		operates on an authorization policy.
	subsequently creates a new one, URIs associated the new context MUST
	be different from those generated for the previous context.		Location URIs that operate on authorization by possession MUST be
	[I-D.ietf-geopriv-http-location-delivery] and		difficult to guess. Inclusion of a sequence of characters with at
	[I-D.ietf-geopriv-lbyr-requirements] provide guidance on the creation		least 128 bits of random entropy is RECOMMENDED. More entropy might
	and desired characteristcs of a location URI.		be required for location URIs with longer lifetimes. If the LIS
			permits changing of the authorization model that applies to a
			context, then the more stringent requirements MUST be complied with.
	The context identifier provided by the LIS to the Target in the		The context identifier provided by the LIS to the Target in the
	context response message MUST be unique and MUST be different from		context response message MUST be unique. Context identifiers are
	the identifier provided in any location URI, and it MUST NOT be		secrets used to indicate authorization for context update requests.
	feasible to determine the context-ID from the location URI. This		Therefore, context identifiers MUST NOT be easily guessable.
	constraint ensures that possession of a location URI does not		Inclusion of a sequence of characters with at least 128 bits of
	automatically provide access and control over the internals of the		random entropy is RECOMMENDED.
	context. It MAY be feasible to determined the location URI knowing
	the context-ID however.
	A context identifier is generated by a LIS to uniquely identify a		A location URI MUST NOT include information that could be used in any
	context. It MUST NOT be feasible for a third-party to easily		way to derive the value of a context identifier. Similarly, context
	determine a context identifier by knowing the identity of the Target.		identifiers MUST NOT be based on Target identity.
	This implies that internal correlation (using a hash-table or
	similar) is the only method that the LIS can use to associate a
	context id with a particular Target.
	6. XML Schema		New contexts MUST have unique location URIs that have not previously
			been used for other contexts, even if the previous context was for
			the same Target.
	<?xml version="1.0"?>		5. XML Schema
	<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:heldCx="urn:ietf:params:xml:ns:geopriv:held:context"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:simpleType name="codeType">		<?xml version="1.0"?>
	<xs:restriction base="xs:token">		<xs:schema
	<xs:enumeration value="created"/>		targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"
	<xs:enumeration value="updated"/>		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	<xs:enumeration value="destroyed"/>		xmlns:ctxt="urn:ietf:params:xml:ns:geopriv:held:context"
	</xs:restriction>		xmlns:cp="urn:ietf:params:xml:ns:common-policy"
	</xs:simpleType>		xmlns:xml="http://www.w3.org/XML/1998/namespace"
			elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:simpleType name="useType">		<xs:annotation>
	<xs:union memberTypes="xs:positiveInteger">		<xs:appinfo
	<xs:simpleType>		source="urn:ietf:params:xml:schema:geopriv:held:context">
	<xs:restriction base="xs:token">		HELD Context Management
	<xs:enumeration value="unlimited"/>		</xs:appinfo>
	</xs:restriction>		<xs:documentation source="http://www.ietf.org/rfc/rfcXXXX.txt">
	</xs:simpleType>		<!-- [[NOTE TO RFC-EDITOR: Please replace above URL with URL of
	</xs:union>		published RFC and remove this note.]] -->
	</xs:simpleType>		This document defines messages for HELD context management.
			</xs:documentation>
			</xs:annotation>
	<xs:complexType name="createContextMsg">		<xs:import namespace="urn:ietf:params:xml:ns:common-policy"/>
	<xs:complexContent>
	<xs:restriction base="xs:anyType">
	<xs:sequence>
	<xs:element name="lifeTime" type="xs:nonNegativeInteger "
	minOccurs="1" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>
	<xs:attribute name="uses" type="heldCx:useType"
	use="optional" default="unlimited"/>
	<xs:attribute name="snapshot" type="xs:boolean"
	use="optional" default="false"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="uriSetType">		<xs:complexType name="policyType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:choice>
	<xs:element name="locationURI" type="xs:anyURI"		<xs:element name="ruleset-reference" type="xs:anyURI"/>
	minOccurs="0" maxOccurs="unbounded"/>		<xs:element ref="cp:ruleset"/>
	</xs:sequence>		<xs:element name="possession" type="ctxt:empty"/>
	</xs:restriction>		<xs:element name="otherPolicy" type="xs:anyType"/>
	</xs:complexContent>		</xs:choice>
			</xs:restriction>
			</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="contextResponseMsg">		<xs:complexType name="createContextType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="locationUriSet" type="heldCx:uriSetType"		<xs:element name="lifeTime" type="xs:nonNegativeInteger"/>
	minOccurs="1" maxOccurs="1"/>		<xs:element name="snapshot" type="xs:boolean"/>
	<xs:any namespace="##other" processContents="lax"		<xs:element name="policy" type="ctxt:policyType"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0"/>
	</xs:sequence>		<xs:any namespace="##other" processContents="lax"
	<xs:attribute name="id" type="xs:token"		minOccurs="0" maxOccurs="unbounded"/>
	use="required"/>		</xs:sequence>
	<xs:attribute name="expires" type="xs:dateTime"		<xs:anyAttribute namespace="##any" processContents="lax"/>
	use="required"/>		</xs:restriction>
	<xs:attribute name="uses" type="xs:positiveInteger"		</xs:complexContent>
	use="optional"/>		</xs:complexType>
	<xs:attribute name="snapshot" type="xs:boolean"
	use="optional"/>
	<xs:attribute name="code" type="heldCx:codeType"
	use="required"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>
	</xs:complexContent>
	</xs:complexType>
	<xs:complexType name="updateContextMsg">		<xs:complexType name="updateContextType">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="xs:anyType">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="lifeTime" type="xs:nonNegativeInteger "		<xs:element name="context-id" type="xs:NCName"/>
	minOccurs="0" maxOccurs="1"/>		<xs:element name="lifeTime" type="xs:nonNegativeInteger"
	<xs:any namespace="##other" processContents="lax"		minOccurs="0"/>
	minOccurs="0" maxOccurs="unbounded"/>		<xs:element name="policy" type="ctxt:policyType"
	</xs:sequence>		minOccurs="0"/>
	<xs:attribute name="id" type="xs:token"		<xs:any namespace="##other" processContents="lax"
	use="required"/>		minOccurs="0" maxOccurs="unbounded"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		</xs:sequence>
	</xs:restriction>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:complexContent>		</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
	</xs:complexType>		<xs:simpleType name="codeType">
			<xs:restriction base="xs:token">
			<xs:enumeration value="created"/>
			<xs:enumeration value="updated"/>
			<xs:enumeration value="destroyed"/>
			</xs:restriction>
			</xs:simpleType>
	<xs:element name="createContext" type="heldCx:createContextMsg"/>		<xs:complexType name="uriSetType">
	<xs:element name="updateContext" type="heldCx:updateContextMsg"/>		<xs:complexContent>
	<xs:element name="contextResponse" type="heldCx:contextResponseMsg"/>		<xs:restriction base="xs:anyType">
			<xs:sequence>
			<xs:element name="locationURI" type="xs:anyURI"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
	</xs:schema>		<xs:complexType name="contextType">
			<xs:complexContent>
			<xs:restriction base="xs:anyType">
			<xs:sequence>
			<xs:element name="locationUriSet" type="ctxt:uriSetType"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="id" type="xs:ID" use="required"/>
			<xs:attribute name="expires" type="xs:dateTime"
			use="required"/>
			<xs:attribute name="snapshot" type="xs:boolean"
			use="optional"/>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
			<xs:complexType name="contextResponseType">
			<xs:complexContent>
			<xs:restriction base="xs:anyType">
			<xs:sequence>
			<xs:element name="context" type="ctxt:contextType"/>
			<xs:any namespace="##other" processContents="lax"
			minOccurs="0" maxOccurs="unbounded"/>
			</xs:sequence>
			<xs:attribute name="code" type="ctxt:codeType"
			use="required"/>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
			</xs:restriction>
			</xs:complexContent>
			</xs:complexType>
	Figure 6: Context Management Schema		<xs:element name="createContext" type="ctxt:createContextType"/>
			<xs:element name="updateContext" type="ctxt:updateContextType"/>
			<xs:element name="contextResponse" type="ctxt:contextResponseType"/>
	7. Security Considerations		</xs:schema>
	There are several security concerns associated with the details in		6. Security Considerations
	this specification. The first is to do with the nature of the
	sensitivity of any data passed from the Target to the LIS for		The data that is maintained in a HELD context is privacy sensitive
	inclusion in a context. The second is the ability of the LIS to		information. This information is provided by a Device for the
	contain the number of contexts that it will permit to exist for a		purposes of providing authorized Location Recipients with location
	given Target address. Finally, there is a threat of Targets		information. The LIS MUST NOT use the information it stores in a
	performing DoS attacks on the LIS by trying to create large numbers		HELD context for anything other than serving requests to the
	of short-lived contexts that result in the LIS expending resources in		associated location URIs.
	message processing.
			The LS MUST enforce the authorization policy established by the
			Device. The authorization policy determines which Location
			Recipients are permitted to receive location information, and how
			that location information is provided. An authorization policy can
			be updated by the Device at any time using the update context
			request; after the LIS responds to this request, the authorization
			policy applies to all subsequent requests from Location Recipients.
			An authorization policy can be referenced using "ruleset-reference"
			in a create context or update context request. The LS MUST retrieve
			any referenced authorization policy using HTTP over TLS [RFC2818]
			before providing location information to any Location Recipient.
			Context identifiers are confidential information shared only between
			LIS and Device. Location URIs are also confidential if authorization
			by possession is chosen by the device, in which case the location URI
			is shared only between LIS, Device and authorized Location
			Recipients. The LIS MUST ensure that context identifiers and
			location URIs are constructed following the rules described in
			Section 4.5 of this document.
	HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of		HELD [I-D.ietf-geopriv-http-location-delivery] mandates the use of
	TLS for exchanges between a Target and the LIS. This is deemed		TLS for exchanges between a Device and the LIS. TLS provides
	adequate to provide confidentiality to any contextual data in		confidentiality, protection from modification, LIS (and possibly
	transit. The LIS implementation and the operator of the LIS need to		Device) authentication. Messages related to HELD contexts contain
	take sufficient steps to ensure that active contextual data on the		information that requires the same protections.
	LIS is not readily available to anyone other than the Target. The
	Target MUST NOT provide any information to the LIS that it does not
	want the LIS to know or be able to use in some capacity associated
	with determination or providing of the Target's location.
	It is quite conceivable that a LIS will be required to provide		6.1. Multiple Contexts from the 'Same' Target
	location to Targets residing behind a NAT; a DSL home router with 5
	PCs attached is a good example this situation. In this case it is
	reasonable for each device to create its own context on the LIS, and
	for the LIS to treat each context individually even though the LIS
	cannot make any other distinction between the end hosts; that is,
	they share a common IP address/identity from the LIS perspective.
	Given the constraints that can be added to a context and the way that		It is conceivable that a LIS will be required to provide location to
	a Target might want to manage expiry separately, a Target may use		Devices residing behind a NAT. A home gateway is a good example of a
	multiple contexts as a way to isolate applications from each other.		situation where the relatively small geographic area served by the
	For instance, a Target can create a context for each application so		gateway is adequately served by a LIS external to that network.
	that it can revoke access to its location information for each		Devices within the home network appear to have the same identity
	without affecting other applications' access. This environment,		information to a LIS - requests all originate from the same IP
	however, opens the LIS to a type of denial of service attack through		address. In this case, each Device might create its own context on
	an overload of contexts. It is RECOMMENDED that an implementer of		the LIS. The LIS treats each context individually even though the
	this specification include mechanisms to restrict to the maximum		LIS might be unable to distinguish between the actual Devices making
	number of contexts that can be created on the LIS by an individual		the requests.
	Target.
	Using short-term location URIs in a carefully controlled manner may		It is also possible that a single Device could request multiple
	obviate the need for individual location authorization policies on		contexts. Devices might have multiple users, or multiple
	the LIS. This leads to reduced LIS complexity and the amount of		applications running that each have have different privileges,
	private information that the Target need share with the LIS. This		different privacy requirements or different Rule Makers. Therefore,
	specification provides the ability for a Target to cancel a location		might create different contexts for different uses: each might a
	URI which extends the Target's ability to enforce its entitlement to		different policy that reflects the needs of the user or application.
	privacy. Using the mechanisms described in this memo a target can		Information provided by a Device related to a context MUST NOT be
	create URIs with short validity periods; this restricts how long a		used by the LIS outside of that context.
	third-party is able to obtain the location of the Target while still
	allowing the Target the convenience of using a location reference.
	The generation of context identifiers by the LIS is a critical		The state information maintained by the LIS or LS in providing a
	component to supporting the functionality described in this memo.		context presents a denial of service attack vector. Limiting the
	The LIS MUST follow the rules described in Section 5.5 for generating		number of contexts that the LIS allows to be created can protect
	context identifiers.		against such attacks. Any limits need to consider the usage pattern
			expected. If home gateways are commonly deployed in the access
			network, then the LIS MUST allow for more than one context for each
			discrete identifier. However, to ensure that LIS resources are not
			exhausted, the LIS MUST limit the number of contexts that it permits
			from each identifier.
	8. IANA Considerations		7. IANA Considerations
	This document registers the schema and associated namespace with		This document registers the schema and associated namespace with
	IANA.		IANA.
	8.1. URN Sub-Namespace Registration for		7.1. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:geopriv:held:context		urn:ietf:params:xml:ns:geopriv:held:context
	This section registers a new XML namespace,		This section registers a new XML namespace,
	"urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines		"urn:ietf:params:xml:ns:geopriv:held:context", as per the guidelines
	in [RFC3688].		in [RFC3688].
	URI: urn:ietf:params:xml:ns:geopriv:held:context		URI: urn:ietf:params:xml:ns:geopriv:held:context
	Registrant Contact: IETF, GEOPRIV working group,		Registrant Contact: IETF, GEOPRIV working group,
	(geopriv@ietf.org), James Winterbottom		(geopriv@ietf.org), James Winterbottom
	skipping to change at page 18, line 43 ¶		skipping to change at page 17, line 38 ¶
	<body>		<body>
	<h1>Namespace for HELD Context Management Messages</h1>		<h1>Namespace for HELD Context Management Messages</h1>
	<h2>urn:ietf:params:xml:ns:geopriv:held:context</h2>		<h2>urn:ietf:params:xml:ns:geopriv:held:context</h2>
	[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX		[[NOTE TO IANA/RFC-EDITOR: Please update RFC URL and replace XXXX
	with the RFC number for this specification.]]		with the RFC number for this specification.]]
	<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>		<p>See <a href="[[RFC URL]]">RFCXXXX</a>.</p>
	</body>		</body>
	</html>		</html>
	END		END
	8.2. XML Schema Registration		7.2. XML Schema Registration
	This section registers an XML schema as per the guidelines in		This section registers an XML schema as per the guidelines in
	[RFC3688].		[RFC3688].
	URI: urn:ietf:params:xml:schema:geopriv:held:context		URI: urn:ietf:params:xml:schema:geopriv:held:context
	Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),		Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org),
	James Winterbottom (james.winterbottom@andrew.com).		James Winterbottom (james.winterbottom@andrew.com).
	Schema: The XML for this schema can be found as the entirety of		Schema: The XML for this schema can be found as the entirety of
	Figure 6 of this document.		Section 5 of this document.
	8.3. New HELD Error Code Registration		7.3. HELD Error Code Registration
	Reference: RFC-XXXX (i.e., this document)requires the following new		Reference: Section 4.4 of RFCXXXX (i.e., this document) specifies the
	HELD error codes to be added the HELD error code respository defined		following HELD error codes:
	in [I-D.ietf-geopriv-http-location-delivery].
	Error code: badContextMessage		badPolicy
	Error code: unknownContext		unknownContext
	Error code: updateContextFailed		contextFailure
	Error code: createContextFailed		These error codes and their descriptions are added to the HELD error
			code respository defined in
			[I-D.ietf-geopriv-http-location-delivery].
	9. Acknowledgements		8. Acknowledgements
	Thanks to Adam Muhlbauer and Neil Justusson for their comments on the		Thanks to Adam Muhlbauer and Neil Justusson for their comments on the
	pre-version of this draft.		pre-version of this draft.
	Thanks also to Tim Zelinski and Michael Diponio , who pointed out a		Thanks also to Tim Zelinski and Michael Diponio, who pointed out a
	problems while implementing an early revision of this specification.		problems while implementing an early revision of this specification.
	Appendix A. Context Extensions		9. References
	A context contains specific information about a Target and is stored		9.1. Normative References
	on the LIS. As with other protocols it is necessary to consider
	extensibility. When defining context data extensions it is necessary
	to consider how they will be used; this includes not only how to
	provide the information from the Target to the LIS, but also
	acceptance and error indications from the LIS back to the Target.
	For example, a context may be created with several extensions
	included, how does the LIS indicate that extensions 1 and 3 were
	successful but that extension 2 had a problem in its formatting?
	Guidelines for designing context extensions that provide
	functionality are described below.
	Two basic types of context data extension are envisioned. The first		[RFC2119] Bradner, S., "Key words
	consist of data provided by the Target to be consumed by the LIS; for		for use in RFCs to
	example information pertaining to PIDF-LO construction, usage-rules,		Indicate Requirement
	and authorization policies. The second type of data consists of a		Levels", BCP 14, RFC 2119,
	two way exchange between the Target and the LIS; for example		March 1997.
	exchanging location determination capabilities. Extensibility to the
	context scheme is to allow additional elements to be added to the
	context easily. The general idea is shown in Figure 7.
	<hc:createContext		[RFC2818] Rescorla, E., "HTTP Over
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context">		TLS", RFC 2818, May 2000.
	<lifeTime>7200</lifeTime>
	<ex1:extension-1
	xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1">
	<ex1:value>7200</ex1:value>
	</ex1:extension-1>
	<extension-2 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"/>
	<extension-3 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3"/>
	.
	.
	.
	<extension-N xmlns="urn:ietf:params:xml:ns:geopriv:held:exN"/>
	</hc:createContext>
	Figure 7: Create Context with Extensions		[RFC3688] Mealling, M., "The IETF
			XML Registry", BCP 81,
			RFC 3688, January 2004.
	When defining a context data extension it is necessary to ensure that		[RFC4745] Schulzrinne, H.,
	the LIS can provide an adequate response to the Target indicating		Tschofenig, H., Morris,
	acceptance or rejection of the data provided. This may be an		J., Cuellar, J., Polk, J.,
	explicit OK or FAIL message within the extension namespace, it may be		and J. Rosenberg, "Common
	an attribute associated with part of a larger data exchange, or it		Policy: A Document Format
	may result in the LIS failing to create the context at all.		for Expressing Privacy
	Regardless, it is mandatory for a context data extension to provide		Preferences", RFC 4745,
	an indication of success or failure.		February 2007.
	<hc:contextResponse		[I-D.ietf-geopriv-http-location-delivery] Barnes, M., Winterbottom,
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		J., Thomson, M., and B.
	code="created"		Stark, "HTTP Enabled
	id="uhvuhdbnuiehudbnvcujevuijeijcvij"		Location Delivery (HELD)",
	uses="unlimited"		draft-ietf-geopriv-http-
	snapshot="false"		location-delivery-13 (work
	expires="2007-08-01T13:00:00">		in progress),
	<locationUriSet>		February 2009.
	<locationURI>
	held//ls.example.com:9768/357yc6s64ceyoiuy5ax3o
	</locationURI>
	<locationURI>
	sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
	</locationURI>
	</locationUriSet>
	<ex1:extension-1 xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1"
	ex1:response="OK"/>
	<ex2:extension-2 xmlns:ex2="urn:ietf:params:xml:ns:geopriv:held:ex2"
	ex2:response="OK"/>
	<ex3:extension-3		9.2. Informative References
	xmlns:ex3="urn:ietf:params:xml:ns:geopriv:held:ex3">
	<datum-3>data</datum-3>
	<stuff>guff in here for extension</stuff>
	</ex3:extension-3>
	</hc:contextRresponse>
	Figure 8: LIS response to createContext		[RFC3693] Cuellar, J., Morris, J.,
			Mulligan, D., Peterson,
			J., and J. Polk, "Geopriv
			Requirements", RFC 3693,
			February 2004.
	When defining information to be included in a context data extension		[RFC4825] Rosenberg, J., "The
	consideration should be given to how that data can be removed from		Extensible Markup Language
	the context. In some cases it may be necessary to void the context		(XML) Configuration Access
	on the LIS in order to remove information, but this SHOULD be treated		Protocol (XCAP)",
	as a last resort and not used as the primary mechanism for removing		RFC 4825, May 2007.
	data from the context.
	Appendix B. HELD Compliance to IETF Location Configuration Protocol		[I-D.ietf-geopriv-l7-lcp-ps] Tschofenig, H. and H.
	Location Reference Requirements		Schulzrinne, "GEOPRIV
			Layer 7 Location
			Configuration Protocol;
			Problem Statement and
			Requirements", draft-ietf-
			geopriv-l7-lcp-ps-09 (work
			in progress),
			February 2009.
			[I-D.ietf-geopriv-lbyr-requirements] Marshall, R.,
			"Requirements for a
			Location-by-Reference
			Mechanism", draft-ietf-
			geopriv-lbyr-requirements-
			07 (work in progress),
			February 2009.
			[I-D.ietf-geopriv-lis-discovery] Thomson, M. and J.
			Winterbottom, "Discovering
			the Local Location
			Information Server (LIS)",
			draft-ietf-geopriv-lis-
			discovery-09 (work in
			progress), March 2009.
			Appendix A. Compliance to Location by Reference Requirements
	This section describes how HELD and this specification comply to the		This section describes how HELD and this specification comply to the
	LCP location reference requirements stipulated in		location configuration protocol requirements stipulated in
	[I-D.ietf-geopriv-lbyr-requirements].		[I-D.ietf-geopriv-lbyr-requirements].
	High-level requirements for a location configuration protocol.		C1. "Location URI support: The configuration protocol MUST support
			a location reference in URI form."
	C1. "Location URI support - LCP: The configuration protocol MUST		Compliant: HELD only provides location references in URI form.
	support a location reference in URI form."
	COMPLY. HELD only provides location references in URI form.		C2. "Location URI expiration: When a location URI has a limited
			validity interval, its lifetime MUST be indicated."
	C2. "Location URI expiration: The LCP MUST support the ability to		Compliant: All location URIs provided expire; the context
	specify to the server, the length of time that a location URI		response message indicates when the URI expires.
	will be valid."
	COMPLY. HELD with the context management extensions described		C3. "Location URI cancellation: The location configuration protocol
	in this document provide the Target the ability to specify		MUST support the ability to request a cancellation of a
	expiry times for location URIs.		specific location URI."
	C3. "Location URI cancellation: The LCP MUST support the ability to		Compliant: Updating a context with a lifetime set to zero
	request a cancellation of a specific location URI."		cancels a context.
	COMPLY. HELD with the context management extensions described		C4. "Location Information Masking: The location URI form MUST,
	in this document provide the Target the ability to void location		through randomization and uniqueness, ensure that any location
	URIs when required.		specific information embedded within the location URI itself is
			kept obscure during location configuration."
	C4. "Random Generated: The location URI MUST be hard to guess, i.e.,		Compliant: With an explicit reference to this requirement, the
	it MUST contain a cryptographically random component."		URIs produced for a HELD context are required to comply with
			this condition.
	COMPLY. The HELD specification and this document provide		C5. "User Identity Protection: The location URI MUST NOT contain
	specific guidance on the security surrounding location URI		any user identifying information that identifies the user,
	generation.		device or address of record, (e.g., which includes phone
			extensions, badge numbers, first or last names, etc.), within
			the URI form."
	C5. "Identity Protection - LCP: The location URI MUST NOT contain		Compliant: With an explicit reference to this requirement, the
	any information that identifies the user, device or address of		URIs produced for a HELD context are required to comply with
	record within the URI form."		this condition.
	COMPLY. The HELD specification and this document provide
	specific guidance on the anonymity of the Target with regards to
	the generation of location URIs.
	C6. "Reuse flag default: The LCP MUST support the default condition		C6. "Reuse indicator: There SHOULD be a way to allow a client to
	of a requested location URI being repeatedly reused."		control whether a location URI can be resolved once only, or
			multiple times."
	COMPLY. HELD with the context management extensions described		Not compliant.
	in this document provide the Target the ability to specify how
	many times a location URI may yield the location of Target.
	C7. "One-time-use: The LCP MUST support the ability for the client		C7. "Validity Interval Indication: A location configuration
	to request a 'one-time-use' location URI (e.g., via a reuse flag		protocol MUST provide an indication of the location URI
	setting)."		validity interval (i.e., expiry time) when present."
	COMPLY. HELD with the context management extensions described		Compliant: The "expires" attribute indicates the time when the
	in this document provide the Target the ability to specify how		context becomes invalid.
	many times a location URI may yield the location of Target.
	This value may be set to 1 to create a one-time URI.
	10. Normative References		C8. "Location only: The location URI MUST NOT point to any
			information about the Target other than it's location."
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		Compliant: PIDF-LO documents that are produced by the LS in
	Requirement Levels", BCP 14, RFC 2119, March 1997.		response to a request at the URI do not contain Target
			identification, unless policy states otherwise.
	[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and		C9. "Location URI Not guessable: Where location URIs are used
	J. Polk, "Geopriv Requirements", RFC 3693, February 2004.		publicly, any location URI MUST be constructed using properties
			of uniqueness and cryptographically random sequences so that it
			is not guessable. (Note that the number of bits depends to
			some extent on the number of active location URIs that might
			exist at the one time; 128-bit is most likely enough for the
			near term.)"
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		Compliant: Section 4.5 describes how this requirement is met by
	January 2004.		implementations.
	[I-D.ietf-geopriv-http-location-delivery]		C10. "Location URI Optional: In the case of user-provided
	Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,		authorization policies, where anonymous or non-guessable
	"HTTP Enabled Location Delivery (HELD)",		location URIs are not warranted, the location configuration
	draft-ietf-geopriv-http-location-delivery-09 (work in		protocol MAY support optional location URI forms."
	progress), September 2008.
	[I-D.ietf-geopriv-l7-lcp-ps]		Not compliant: The format of location URIs generated by the LIS
	Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		cannot be influenced through any of the parameters described in
	Location Configuration Protocol; Problem Statement and		this document.
	Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
	progress), June 2008.
	[I-D.ietf-geopriv-lbyr-requirements]		C11. "Location URI Authorization Model: The location configuration
	Marshall, R., "Requirements for a Location-by-Reference		protocol SHOULD indicate whether the requested location URI
	Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work		conforms to the access control authorization model or the
	in progress), July 2008.		possession authorization model."
			Compliant: The authorization model is explicitly selected by
			the Device in the request.
			C12. "Location URI Lifetime: A location URI SHOULD have an
			associated expiration lifetime (i.e., validity interval), and
			MUST have an validity interval if used with the possession
			authorization model."
			Duplicate requirement.
	Authors' Addresses		Authors' Addresses
	James Winterbottom		James Winterbottom
	Andrew Corporation		Andrew Corporation
	PO Box U40		PO Box U40
	University of Wollongong, NSW 2500		University of Wollongong, NSW 2500
	AU		AU
	Phone: +61 242 212938		Phone: +61 242 212938
	Email: james.winterbottom@andrew.com		EMail: james.winterbottom@andrew.com
	URI: http://www.andrew.com/products/geometrix		URI: http://www.andrew.com/products/geometrix
	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
	Martin Thomson		Martin Thomson
	Andrew Corporation		Andrew Corporation
	PO Box U40		PO Box U40
	University of Wollongong, NSW 2500		University of Wollongong, NSW 2500
	AU		AU
	Phone: +61 242 212915		Phone: +61 242 212915
	Email: martin.thomson@andrew.com		EMail: martin.thomson@andrew.com
	URI: http://www.andrew.com/products/geometrix		URI: http://www.andrew.com/products/geometrix
	Full Copyright Statement
	Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.
	This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
	THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
	WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
	Intellectual Property
	The IETF takes no position regarding the validity or scope of any
	Intellectual Property Rights or other rights that might be claimed to
	pertain to the implementation or use of the technology described in
	this document or the extent to which any license under such rights
	might or might not be available; nor does it represent that it has
	made any independent effort to identify any such rights. Information
	on the procedures with respect to rights in RFC documents can be
	found in BCP 78 and BCP 79.
	Copies of IPR disclosures made to the IETF Secretariat and any
	assurances of licenses to be made available, or the result of an
	attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.
End of changes. 144 change blocks.
	566 lines changed or deleted		738 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/