< draft-winterbottom-geopriv-held-context-01.txt		draft-winterbottom-geopriv-held-context-02.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 8, 2008 Nokia Siemens Networks		Expires: August 23, 2008 Nokia Siemens Networks
	M. Thomson		M. Thomson
	Andrew Corporation		Andrew Corporation
	October 6, 2007		February 20, 2008
	HELD Protocol Context Management Extensions		HELD Protocol Context Management Extensions
	draft-winterbottom-geopriv-held-context-01.txt		draft-winterbottom-geopriv-held-context-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37 ¶		skipping to change at page 1, line 37 ¶
	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 8, 2008.		This Internet-Draft will expire on August 23, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	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
	skipping to change at page 2, line 29 ¶		skipping to change at page 2, line 29 ¶
	2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
	3. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5		3. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5
	4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6		4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6		4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6
	4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7		4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7
	4.3. Location Type URIs . . . . . . . . . . . . . . . . . . . . 7		4.3. Location Type URIs . . . . . . . . . . . . . . . . . . . . 7
	5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8		5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
	5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8		5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8
	5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9		5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9
	5.3. Context Response Message . . . . . . . . . . . . . . . . . 10		5.3. Context Response Message . . . . . . . . . . . . . . . . . 10
	5.4. Context Error Messages . . . . . . . . . . . . . . . . . . 12		5.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 12
	5.5. Location URI and Context Identifier Generation Rules . . . 12		5.5. Location URI and Context Identifier Generation Rules . . . 12
	6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14		6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8.1. URN Sub-Namespace Registration for		8.1. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 19		urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 19
	8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 19		8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 19
			8.3. New HELD Error Code Registration . . . . . . . . . . . . . 20
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22		Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22
	Appendix B. HELD Compliance to IETF Location Configuration		Appendix B. HELD Compliance to IETF Location Configuration
	Protocol Location Reference Requirements . . . . . . 24		Protocol Location Reference Requirements . . . . . . 24
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 26		10. Normative References . . . . . . . . . . . . . . . . . . . . . 26
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
	Intellectual Property and Copyright Statements . . . . . . . . . . 28		Intellectual Property and Copyright Statements . . . . . . . . . . 28
	1. Introduction		1. Introduction
	skipping to change at page 5, line 23 ¶		skipping to change at page 5, line 23 ¶
	from the URI to the Target's location. This specification provides a		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		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.		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		A context expires when it reaches a certain age, at which time the
	mapping between the URI and the Target's location ceases. In the		mapping between the URI and the Target's location ceases. In the
	basic HELD specification the exiry time of the context is determined		basic HELD specification the exiry time of the context is determined
	by the LIS when the Target requests a location URI. By allowing the		by the LIS when the Target requests a location URI. By allowing the
	Target to specify and change the life time of a context the Target is		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		able to create URIs for limited periods, or to terminate URIs for
	which it longer wishes its location to be returned. This		which it no longer wishes its location to be returned. This
	specification provides explicit support for this functionality.		specification provides explicit support for this functionality.
	4. Constraints		4. Constraints
	Constraints restrict the ability of a Location Recipient to resolve a		Constraints restrict the ability of a Location Recipient to resolve a
	location URI to location information. The constraints are selected		location URI to location information. The constraints are selected
	by the Target and they are provided to the LIS that maintains them		by the Target and they are provided to the LIS that maintains them
	along with the context. A LIS, understanding this specification,		along with the context. A LIS, understanding this specification,
	receives constraints provided by the Target, and returns a set of		receives constraints provided by the Target, and returns a set of
	URIs influenced by the constraints.		URIs influenced by the constraints.
	A single Target may want to place different contraints on different		A single Target may want to place different contraints on different
	references and hence may have multiple contexts on the LIS. The		references and hence may have multiple contexts on the LIS. The
	constraints describe what actions the LIS MUST take when a URI		constraints describe what actions the LIS MUST take when a URI
	associated with the context is accessed. This document describes		associated with the context is accessed. This document describes
	three basic constraints that a Target can use in comination for the		three basic constraints that a Target can use in combination for the
	same context. Once set, these rules remain in force of the life of		same context. Once set, these rules remain in force of the life of
	the context.		the context.
	4.1. Limited Use URIs		4.1. Limited Use URIs
	A limited use URI can only be accessed a fixed number of times to		A limited use URI can only be accessed a fixed number of times to
	yield the location of the Target. Each time the URI is used to		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		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		limit is reached the URI no longer yields the location of the Target
	and the URI is deemed spent.		and the URI is deemed spent.
	skipping to change at page 6, line 42 ¶		skipping to change at page 6, line 42 ¶
	location only once. Setting the usage limit to something higher than		location only once. Setting the usage limit to something higher than
	1 creates functionality analogous to a metro-ticket, where a Location		1 creates functionality analogous to a metro-ticket, where a Location
	Recipient in possession of the URI can access the Target's location		Recipient in possession of the URI can access the Target's location
	many more times, but not exceeding the imposed limit.		many more times, but not exceeding the imposed limit.
	Not setting a usage limit provides similar semantics to the URI in		Not setting a usage limit provides similar semantics to the URI in
	the base HELD specification, enabling a Location Recipient to		the base HELD specification, enabling a Location Recipient to
	continually obtain the Target's location until the URI expires due to		continually obtain the Target's location until the URI expires due to
	age.		age.
	When an HTTP URI is assigned to a context, the limit is the number of		When a HELD URI is assigned to a context, the limit is the number of
	times that the URI can be accessed before the LIS returns an error.		times that the URI can be accessed before the LIS returns an error.
	In the case of SIP it is the number of NOTIFY messages that are sent		In the case of SIP or pres URIs it is the number of NOTIFY messages
	prior to the LIS returning an error. Where a context supports both		that are sent prior to the LIS returning an error. Where a context
	SIP and HTTP URIs it is the combination of URI accesses and NOTIFY		supports SIP, pres, and HELD URIs it is the combination of URI
	messages that constitutes the usage value, each time the Target's		accesses and NOTIFY messages that constitutes the usage value, each
	location is provided constitutes a usage.		time the Target's location is provided constitutes a usage.
	4.2. Snapshot URIs		4.2. Snapshot URIs
	A snapshot URI points to the location of the Target at a specific		A snapshot URI points to the location of the Target at a specific
	point in time, and no matter how many times the URI is accessed it		point in time, and no matter how many times the URI is accessed it
	will always yield the same location. This is useful if, for example,		will always yield the same location. This is useful if, for example,
	the Target does not want to be tracked. In this specification the		the Target does not want to be tracked. In this specification the
	location snapshot to which a snapshot URIs points is captured when		location snapshot to which a snapshot URIs points is captured when
	the context is created on the LIS.		the context is created on the LIS.
	4.3. Location Type URIs		4.3. Location Type URIs
	A location type URI controls the form of location that can be		A location type URI controls the form of location that can be
	accessed; This may be geodetic, civic, or both.		accessed; This may be geodetic, civic, or both.
	5. Protocol Details		5. Protocol Details
	This specification introduces four new HELD messages, create context		This specification introduces three new HELD messages, create context
	(<createContext>), update context (<updateContext>), context response		(<createContext>), update context (<updateContext>), and context
	(<contextResponse>), and context error (<contextError>). A LIS that		response (<contextResponse>). A LIS that does not understand this
	does not understand this specification is expected to return a HELD		specification is expected to return a HELD _unsupportedMessage_ error
	_unsupportedMessage_ error code in a HELD error message.		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		The specification assumes that the LIS was discovered as part of the
	general HELD LIS discovery process. All messages are sent using the		general HELD LIS discovery process. All messages are sent using the
	application/held+xml MIME type as 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		5.1. Create Context Message
	The Target creates a context on the LIS using a create context		The Target creates a context on the LIS using a create context
	message. The basic create context message supports the constraints		message. The basic create context message supports the constraints
	skipping to change at page 8, line 37 ¶		skipping to change at page 8, line 40 ¶
	positive integer, and has a default value of _unlimited_. The LIS		positive integer, and has a default value of _unlimited_. The LIS
	SHOULD support the Target specifying up to at least 100 uses.		SHOULD support the Target specifying up to at least 100 uses.
	o "snapshot": an optional attribute instructing the LIS to take a		o "snapshot": an optional attribute instructing the LIS to take a
	snapshot of the Target's location for use with the context. This		snapshot of the Target's location for use with the context. This
	a boolean value and has a default of _false_ meaning that a		a boolean value and has a default of _false_ meaning that a
	snapshot is not taken, and the Target's location is determined		snapshot is not taken, and the Target's location is determined
	each time the URI is accessed.		each time the URI is accessed.
	o "locationType": an optional attribute instructing the LIS on the		o "locationType": an optional attribute instructing the LIS on the
	form of location that URI MUST provide. This is an enumeration		form of location that the URI MUST return. This is an enumeration
	and may have a value of _geodetic_, _civic_, or _any_. If		and may have a value of _geodetic_, _civic_, or _any_. If
	unspecified by the Target the LIS will use a value of _any_. If		unspecified by the Target the LIS will use a value of _any_. If
	the Target specifies a location type that the LIS cannot provide,		the Target specifies a location type that the LIS cannot provide,
	then the LIS MUST fail the context creation.		then the LIS MUST fail the context creation.
	o "lifeTime": is a mandatory element that defines the maximum period		o "lifeTime": is a mandatory element that defines the maximum period
	in seconds that the LIS should keep the context for. The LIS MAY		in seconds that the LIS should keep the context for. The LIS MAY
	create the context with a shorter life time than was requested,		create the context with a shorter life time than was requested,
	but the life time MUST NOT be longer than was requested.		but the life time MUST NOT be longer than was requested.
	<hc:createContext		<createContext
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
	uses="10"		uses="10"
	snapshot="false"		snapshot="false"
	locationType="any">		locationType="any">
	<hc:lifeTime>7200</hc:lifeTime>		<lifeTime>7200</lifeTime>
	</hc:createContext>		</createContext>
	Figure 1: createContext Example		Figure 1: createContext Example
	Figure 1 shows a create context message defining a context which:		Figure 1 shows a create context message defining a context which:
	o may be accessed 10 times		o may be accessed 10 times
	o will determine the location of the Target each time it is accessed		o will determine the location of the Target each time it is accessed
	o will return the location in either geodetic or civic form		o will return the location in either geodetic or civic form
	depending on the request tot he URI		depending on the request to the URI
	o will be valid for 2 hours from the time of context creation		o will be valid for 2 hours from the time of context creation
	5.2. Update Context Message		5.2. Update Context Message
	A Target can change the life time of a context using an update		A Target can change the life time of a context using an update
	context message. As stated in Section 4 the three attributes used in		context message. As stated in Section 4 the three attributes used in
	the context creation, "uses", "snapshot", and "locationType" cannot		the context creation, "uses", "snapshot", and "locationType" cannot
	be changed once a context is created.		be changed once a context is created.
	Since the Target may have more than one context on the LIS, the		Since the Target may have more than one context on the LIS, the
	Target needs to identify the context to be updated. It does this by		Target needs to identify the context to be updated. It does this by
	including a context identifier that is provided to it by the LIS when		including a context identifier that is provided to it by the LIS when
	the context is created.		the context is created.
	<hc:updateContext		<updateContext
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
	hc:id="uhvuhdbnuiehudbnvcujevuijeijcvij3">		id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
	<lifeTime>3600</lifeTime>		<lifeTime>3600</lifeTime>
	</hc:updateContext>		</updateContext>
	Figure 2: updateContext Life Time Change Example		Figure 2: updateContext Life Time Change Example
	When a Target includes a life time element in an update context		When a Target includes a life time element in an update context
	message, the LIS needs to calculate a new context expiry time. The		message, the LIS needs to calculate a new context expiry time. The
	LIS MUST do this by adding the new life time value to the current		LIS MUST do this by adding the new life time value to the current
	time on the LIS. This mechanism means the Target can terminate a		time on the LIS. This mechanism means the Target can terminate a
	context at any time. It does this by updating the context with a		context at any time. It does this by updating the context with a
	life time of 0, which results in the LIS setting the context expiry		life time of 0, which results in the LIS setting the context expiry
	time to the present. The LIS MAY also terminate a context if the		time to the present. The LIS MAY also terminate a context if the
	life time value is set to less than 10 seconds.		life time value is set to less than 10 seconds.
	<hc:updateContext		<updateContext
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
	hc:id="uhvuhdbnuiehudbnvcujevuijeijcvij3">		id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
	<lifeTime>0</lifeTime>		<lifeTime>0</lifeTime>
	</lhc:updateContext>		</updateContext>
	Figure 3: updateContext Termination Example		Figure 3: updateContext Termination Example
	5.3. Context Response Message		5.3. Context Response Message
	The LIS informs the Target about the outcome of context operations		The LIS informs the Target about the outcome of context operations
	through the context response message. The LIS MUST always send a		through the context response message. The LIS MUST always send a
	context response message to a Target in response to a create context		context response message to a Target in response to a create context
	or update context message when the outcome was successful. The		or update context message when the outcome was successful. The
	context response message contains a "code" attribute indicating the		context response message contains a "code" attribute indicating the
	skipping to change at page 10, line 34 ¶		skipping to change at page 10, line 34 ¶
	The "code" attribute is an enumerated type and has one of the		The "code" attribute is an enumerated type and has one of the
	following values:		following values:
	o _created_: The context was successfully created.		o _created_: The context was successfully created.
	o _destroyed_: The context was destroyed.		o _destroyed_: The context was destroyed.
	o _updated_: The context was successfully updated.		o _updated_: The context was successfully updated.
	The following list details the other attributes are may be returned		The following list details the other attributes that may be returned
	in a context response message.		in a context response message.
	id: The identifier allocated to the context by the LIS. This		id: The identifier allocated to the context by the LIS. This
	identifier is unique in the scope of the LIS. The Target MUST		identifier is unique in the scope of the LIS. The Target MUST
	keep this secret and MUST included it in all update requests. The		keep this secret and MUST included it in all update requests. The
	LIS MUST return and "id" in all context response messages.		LIS MUST return an "id" in all context response messages.
	uses: The number of times that the context will yield the Target's		uses: The number of times that the context will yield the Target's
	location. The LIS MAY report either the original value, or the		location. The LIS MAY report either the original value, or the
	number of remaining uses. The LIS MUST report this value for all		number of remaining uses. The LIS MUST report this value for all
	responses pertaining to a known and valid context. This value MAY		responses pertaining to a known and valid context. This value MAY
	be ommitted when indicating that a context has been destroyed.		be ommitted when indicating that a context has been destroyed.
	snapshot: The value of the snapshot attribute in the context. The		snapshot: The value of the snapshot attribute in the context. The
	LIS MUST report this value for all responses pertaining to a known		LIS MUST report this value for all responses pertaining to a known
	and valid context. This value MAY be ommitted when indicating		and valid context. This value MAY be ommitted when indicating
	skipping to change at page 11, line 30 ¶		skipping to change at page 11, line 30 ¶
	of _destroyed_ is included in the context repsonse message.		of _destroyed_ is included in the context repsonse message.
	In addition to the above attributes, the LIS also provides a set of		In addition to the above attributes, the LIS also provides a set of
	URIs that can used to access the Target's location with the surety		URIs that can used to access the Target's location with the surety
	that the context constraints will be applied. A URI set is returned		that the context constraints will be applied. A URI set is returned
	whenever a context is successfully created on the LIS, and this set		whenever a context is successfully created on the LIS, and this set
	remains unchanged for the lifetime of the context. A context		remains unchanged for the lifetime of the context. A context
	response message sent in reply to the create context message in		response message sent in reply to the create context message in
	Figure 1 might look like Figure 4.		Figure 1 might look like Figure 4.
	<hc:contextResponse		<contextResponse
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
	code="created"		code="created"
	id="uhvuhdbnuiehudbnvcujevuijeijcvij4"		id="uhvuhdbnuiehudbnvcujevuijeijcvij4"
	uses="10"		uses="10"
	snapshot="false"		snapshot="false"
	locationType="any"		locationType="any"
	expires="2007-11-01T13:30:00">		expires="2007-11-01T13:30:00">
	<hc:locationUriSet>		<locationUriSet>
	<hc:locationURI>		<locationURI>
	https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4		held://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4
	</hc:locationURI>		</locationURI>
	<hc:locationURI>		<locationURI>
	sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769		sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769
	</hc:locationURI>		</locationURI>
	</hc:locationUriSet>		</locationUriSet>
	</hc:contextResponse>		</contextResponse>
	Figure 4: contextResponse Example		Figure 4: contextResponse Example
	5.4. Context Error Messages		5.4. Context Errors
	When the LIS unable to perform the requested context operation it		When the LIS unable to perform the requested context operation it
	need to inform the Target of this. It does this using a context		need to inform the Target of this. It does this using a held error
	error message. The context error message consists of a "errorCode"		message. New codes are defined for context operation errors:
	and an optional "message" attribute. The code indicates what went
	wrong, the message is human-readable text that may provide additional
	information on what occurred.
	The "errorCode" attribute is an enumerated type and has one of the
	following values:
	o _badMessage_: The LIS was unable to understand the content of the		o _badContextMessage_: The LIS was unable to understand the content
	message.		of the message. In general this will apply to context messages
			containing extensions that the LIS does not understand.
	o _unknownContext_: The LIS was unable to find the context.		o _unknownContext_: The LIS was unable to find the context.
	o _failed_: The LIS was unable to perform the requested operation.		o _updateContextFailed_: The LIS was unable to updated the requested
			context.
	A Target implementing this specification MUST accept a HELD error		o _createContextFailed_: The LIS was unable to created the requested
			context.
			A Target implementing this specification MUST accept a any HELD error
	message as a valid response to a create context or update context		message as a valid response to a create context or update context
	message.		message as a LIS may not understand context messages. A LIS that
			does understand context messages is expected to return the error
			codes above unde the prescribed circumstances.
	<hc:contextError		<error xmlns="urn:ietf:params:xml:ns:geopriv:held"
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		code="createContextFailed"
	code="failed"		message="locationType of Civic is not supported"/>
	message="unable to update context">
	</hc:contextError>
	Figure 5: contextError With Message Example		Figure 5: Example Error Message
	5.5. Location URI and Context Identifier Generation Rules		5.5. Location URI and Context Identifier Generation Rules
	A primary aim of this specification is to provide a Target a means to		A primary aim of this specification is to provide a Target a means to
	cancel a location URI so that it can no longer be used to provide its		cancel a location URI so that it can no longer be used to provide its
	location. To achieve this, a location URI generated as part of a		location. To achieve this, a location URI generated as part of a
	context creation needs to be unique with in the scope of the LIS, and		context creation needs to be unique with in the scope of the LIS, and
	identify only that context. If the Target destroys a context and		identify only that context. If the Target destroys a context and
	subsequently creates a new one, URIs associated the new context MUST		subsequently creates a new one, URIs associated the new context MUST
	be different from those generated for the previous context.		be different from those generated for the previous context.
	[I-D.ietf-geopriv-http-location-delivery] and		[I-D.ietf-geopriv-http-location-delivery] and
	[I-D.ietf-geopriv-lbyr-requirements] provide guideance on the		[I-D.ietf-geopriv-lbyr-requirements] provide guidance on the creation
	creation and desired characteristcs of a location URI.		and desired characteristcs of a location URI.
	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 and MUST be different from
	the identifier provided in any location URI. This latter constraint		the identifier provided in any location URI, and it MUST NOT be
	ensures that possession of a location URI does not automatically		feasible to determine the context-ID from the location URI. This
	provide access and control over the internals of the context.		constraint ensures that possession of a location URI does not
			automatically provide access and control over the internals of the
			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 context identifier is generated by a LIS to uniquely identify a
	context. It MUST NOT be feasible for a third-party to easily		context. It MUST NOT be feasible for a third-party to easily
	determine a context identifier by knowing the identity of the Target.		determine a context identifier by knowing the identity of the Target.
	This implies that internal correlation (using a hash-table or		This implies that internal correlation (using a hash-table or
	similar) is the only method that the LIS can use to associate a		similar) is the only method that the LIS can use to associate a
	context id with a particular Target.		context id with a particular Target.
	6. XML Schema		6. XML Schema
	skipping to change at page 14, line 31 ¶		skipping to change at page 14, line 31 ¶
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="codeType">		<xs:simpleType name="codeType">
	<xs:restriction base="xs:token">		<xs:restriction base="xs:token">
	<xs:enumeration value="created"/>		<xs:enumeration value="created"/>
	<xs:enumeration value="updated"/>		<xs:enumeration value="updated"/>
	<xs:enumeration value="destroyed"/>		<xs:enumeration value="destroyed"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:simpleType name="errorCodeType">
	<xs:restriction base="xs:token">
	<xs:enumeration value="badMessage"/>
	<xs:enumeration value="unknownContext"/>
	<xs:enumeration value="failed"/>
	</xs:restriction>
	</xs:simpleType>
	<xs:simpleType name="useType">		<xs:simpleType name="useType">
	<xs:union>		<xs:union memberTypes="xs:positiveInteger">
	<xs:simpleType>		<xs:simpleType>
	<xs:restriction base="xs:token">		<xs:restriction base="xs:token">
	<xs;enumeration value="unlimited"/>		<xs:enumeration value="unlimited"/>
	</xs:restriction>		</xs:restriction>
	</xs:simpleType>		</xs:simpleType>
	<xs:positiveInteger/>
	</xs:union>		</xs:union>
	</xs:simpleType>		</xs:simpleType>
	<xs:complexType name="createContextMsg">		<xs:complexType name="createContextMsg">
	<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="lifeTime" type="xs:nonNegativeInteger "
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	skipping to change at page 15, line 13 ¶		skipping to change at page 15, line 4 ¶
	<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="lifeTime" type="xs:nonNegativeInteger "
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="uses" type="heldCx:useType"		<xs:attribute name="uses" type="heldCx:useType"
	use="optional" default="unlimited"/>		use="optional" default="unlimited"/>
	<xs:attribute name="snapshot" type="xs:boolean"		<xs:attribute name="snapshot" type="xs:boolean"
	use="optional" default="false"/>		use="optional" default="false"/>
	<xs:attribute name="locationType" type="heldCx:locationType"		<xs:attribute name="locationType" type="heldCx:locationType"
	use="optional" default="any"/>		use="optional" default="any"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="uriSetType">		<xs:complexType name="uriSetType">
	<xs:complexContent>		<xs:complexContent>
			<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="locationURI" type="xs:anyURI"		<xs:element name="locationURI" type="xs:anyURI"
	maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
			</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="contextResponseMsg">		<xs:complexType name="contextResponseMsg">
	<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="locationUriSet" type="heldCx:uriSetType"
	minOccurs="1" maxOccurs="1"/>		minOccurs="1" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	skipping to change at page 16, line 4 ¶		skipping to change at page 15, line 46 ¶
	<xs:attribute name="expires" type="xs:dateTime"		<xs:attribute name="expires" type="xs:dateTime"
	use="required"/>		use="required"/>
	<xs:attribute name="uses" type="xs:positiveInteger"		<xs:attribute name="uses" type="xs:positiveInteger"
	use="optional"/>		use="optional"/>
	<xs:attribute name="snapshot" type="xs:boolean"		<xs:attribute name="snapshot" type="xs:boolean"
	use="optional"/>		use="optional"/>
	<xs:attribute name="locationType" type="heldCx:locationType"		<xs:attribute name="locationType" type="heldCx:locationType"
	use="optional"/>		use="optional"/>
	<xs:attribute name="code" type="heldCx:codeType"		<xs:attribute name="code" type="heldCx:codeType"
	use="required"/>		use="required"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="updateContextMsg">		<xs:complexType name="updateContextMsg">
	<xs:complexContent>		<xs:complexContent>
	<xs:restriction base="heldCx:">		<xs:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="lifeTime" type="xs:nonNegativeInteger "		<xs:element name="lifeTime" type="xs:nonNegativeInteger "
	minOccurs="0" maxOccurs="1"/>		minOccurs="0" maxOccurs="1"/>
	<xs:any namespace="##other" processContents="lax"		<xs:any namespace="##other" processContents="lax"
	minOccurs="0" maxOccurs="unbounded"/>		minOccurs="0" maxOccurs="unbounded"/>
	</xs:sequence>		</xs:sequence>
	<xs:attribute name="id" type="xs:token"		<xs:attribute name="id" type="xs:token"
	use="required"/>		use="required"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>		<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
	<xs:complexType name="contextErrorMsg">
	<xs:complexContent>
	<xs:restriction base="xs:anyType">
	<xs:sequence/>
	<xs:attribute name="errorCode" type="heldCx:errorCodeType"
	use="required"/>
	<xs:attribute name="message" type="xs:token"
	use="optional"/>
	<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>
	</xs:complexContent>
	</xs:complexType>
	<xs:element name="createContext" type="heldCx:createContextMsg"/>		<xs:element name="createContext" type="heldCx:createContextMsg"/>
	<xs:element name="updateContext" type="heldCx:updateContextMsg"/>		<xs:element name="updateContext" type="heldCx:updateContextMsg"/>
	<xs:element name="contextResponse" type="heldCx:contextResponseMsg"/>		<xs:element name="contextResponse" type="heldCx:contextResponseMsg"/>
	<xs:element name="contextError" type="heldCx:contextErrorMsg"/>
	</xs:schema>		</xs:schema>
	Figure 6: Context Management Schema		Figure 6: Context Management Schema
	7. Security Considerations		7. Security Considerations
	There are several security concerns associated with the details in		There are several security concerns associated with the details in
	this specification. The first is to do with the nature of the		this specification. The first is to do with the nature of the
	sensitivity of any data passed from the Target to the LIS for		sensitivity of any data passed from the Target to the LIS for
	skipping to change at page 21, line 5 ¶		skipping to change at page 20, line 10 ¶
	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.		Figure 6 of this document.
			8.3. New HELD Error Code Registration
			Reference: RFC-XXXX (i.e., this document)requires the following new
			HELD error codes to be added the HELD error code respository defined
			in [I-D.ietf-geopriv-http-location-delivery].
			Error code: badContextMessage
			Error code: unknownContext
			Error code: updateContextFailed
			Error code: createContextFailed
	9. Acknowledgements		9. 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
			problems while implementing an early revision of this specification.
	Appendix A. Context Extensions		Appendix A. Context Extensions
	A context contains specific information about a Target and is stored		A context contains specific information about a Target and is stored
	on the LIS. As with other protocols it is necessary to consider		on the LIS. As with other protocols it is necessary to consider
	extensibility. When defining context data extensions it is necessary		extensibility. When defining context data extensions it is necessary
	to consider how they will be used; this includes not only how to		to consider how they will be used; this includes not only how to
	provide the information from the Target to the LIS, but also		provide the information from the Target to the LIS, but also
	acceptance and error indications from the LIS back to the Target.		acceptance and error indications from the LIS back to the Target.
	For example, a context may be created with several extensions		For example, a context may be created with several extensions
	included, how does the LIS indicate that extensions 1 and 3 were		included, how does the LIS indicate that extensions 1 and 3 were
	skipping to change at page 23, line 16 ¶		skipping to change at page 23, line 16 ¶
	<hc:contextResponse		<hc:contextResponse
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
	code="created"		code="created"
	id="uhvuhdbnuiehudbnvcujevuijeijcvij"		id="uhvuhdbnuiehudbnvcujevuijeijcvij"
	uses="unlimited"		uses="unlimited"
	snapshot="false"		snapshot="false"
	locType="any"		locType="any"
	expires="2007-08-01T13:00:00">		expires="2007-08-01T13:00:00">
	<locationUriSet>		<locationUriSet>
	<locationURI>		<locationURI>
	https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o		held//ls.example.com:9768/357yc6s64ceyoiuy5ax3o
	</locationURI>		</locationURI>
	<locationURI>		<locationURI>
	sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769		sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
	</locationURI>		</locationURI>
	</locationUriSet>		</locationUriSet>
	<ex1:extension-1 xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1"		<ex1:extension-1 xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1"
	ex1:response="OK"/>		ex1:response="OK"/>
	<ex2:extension-2 xmlns:ex2="urn:ietf:params:xml:ns:geopriv:held:ex2"		<ex2:extension-2 xmlns:ex2="urn:ietf:params:xml:ns:geopriv:held:ex2"
	ex2:response="OK"/>		ex2:response="OK"/>
	skipping to change at page 26, line 19 ¶		skipping to change at page 26, line 19 ¶
	[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.
	[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,		[RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
	January 2004.		January 2004.
	[I-D.ietf-geopriv-http-location-delivery]		[I-D.ietf-geopriv-http-location-delivery]
	Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,		Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
	"HTTP Enabled Location Delivery (HELD)",		"HTTP Enabled Location Delivery (HELD)",
	draft-ietf-geopriv-http-location-delivery-02 (work in		draft-ietf-geopriv-http-location-delivery-04 (work in
	progress), September 2007.		progress), January 2008.
	[I-D.ietf-geopriv-l7-lcp-ps]		[I-D.ietf-geopriv-l7-lcp-ps]
	Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7		Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
	Location Configuration Protocol; Problem Statement and		Location Configuration Protocol; Problem Statement and
	Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in		Requirements", draft-ietf-geopriv-l7-lcp-ps-06 (work in
	progress), September 2007.		progress), November 2007.
	[I-D.ietf-geopriv-lbyr-requirements]		[I-D.ietf-geopriv-lbyr-requirements]
	Marshall, R., "Requirements for a Location-by-Reference		Marshall, R., "Requirements for a Location-by-Reference
	Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work		Mechanism", draft-ietf-geopriv-lbyr-requirements-01 (work
	in progress), September 2007.		in progress), October 2007.
	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
	skipping to change at page 28, line 7 ¶		skipping to change at page 28, line 7 ¶
	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		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2008).
	This document is subject to the rights, licenses and restrictions		This document is subject to the rights, licenses and restrictions
	contained in BCP 78, and except as set forth therein, the authors		contained in BCP 78, and except as set forth therein, the authors
	retain all their rights.		retain all their rights.
	This document and the information contained herein are provided on an		This document and the information contained herein are provided on an
	"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS		"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
	OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND		OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
	THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS		THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
	OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF		OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
End of changes. 54 change blocks.
	106 lines changed or deleted		108 lines changed or added
This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/