< draft-winterbottom-geopriv-held-context-02.txt		draft-winterbottom-geopriv-held-context-03.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: August 23, 2008 Nokia Siemens Networks		Expires: April 2, 2009 Nokia Siemens Networks
	M. Thomson		M. Thomson
	Andrew Corporation		Andrew Corporation
	February 20, 2008		September 29, 2008
	HELD Protocol Context Management Extensions		HELD Protocol Context Management Extensions
	draft-winterbottom-geopriv-held-context-02.txt		draft-winterbottom-geopriv-held-context-03.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 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 August 23, 2008.		This Internet-Draft will expire on April 2, 2009.
	Copyright Notice
	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
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 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
	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 Errors . . . . . . . . . . . . . . . . . . . . . . 12		5.4. Context Errors . . . . . . . . . . . . . . . . . . . . . . 11
	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 . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 17		7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19		8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
	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 . . . . . . . 18
	8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 19		8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 18
	8.3. New HELD Error Code Registration . . . . . . . . . . . . . 20		8.3. New HELD Error Code Registration . . . . . . . . . . . . . 19
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20
	Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22		Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 21
	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 . . . . . . 23
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 26		10. Normative References . . . . . . . . . . . . . . . . . . . . . 25
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26
	Intellectual Property and Copyright Statements . . . . . . . . . . 28		Intellectual Property and Copyright Statements . . . . . . . . . . 27
	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 basic HELD specification does
	this in a more or less stateless manner, and when a location URI is		this in a more or less stateless manner, and when a location URI is
	retrieved the Target has no way of controlling how the URI is used; a		retrieved the Target has no way of controlling how the URI is used; a
	Location Recipient in pocession of the location URI can get the		Location Recipient in pocession of the location URI can get the
	skipping to change at page 6, line 17 ¶		skipping to change at page 6, line 17 ¶
	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 two
	three basic constraints that a Target can use in combination for the		basic constraints that a Target can use in combination for the same
	same context. Once set, these rules remain in force of the life of		context. Once set, these rules remain in force of the life of the
	the context.		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.
	By setting the usage limit to 1, the Target is able to create a one-		By setting the usage limit to 1, the Target is able to create a one-
	skipping to change at page 7, line 14 ¶		skipping to change at page 8, line 5 ¶
	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
	A location type URI controls the form of location that can be
	accessed; This may be geodetic, civic, or both.
	5. Protocol Details		5. 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>). A LIS that does not understand this
	specification is expected to return a HELD _unsupportedMessage_ error		specification is expected to return a HELD _unsupportedMessage_ error
	code in a HELD error message. A LIS that does understand this		code in a HELD error message. A LIS that does understand this
	specification returns errors associated with context operations in a		specification returns errors associated with context operations in a
	HELD error message. New error codes relating to failed context		HELD error message. New error codes relating to failed context
	operations are defined in this specification.		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
	described in Section 4 and consist of three attributes and one		described in Section 4 and consist of two attributes and one element
	element described below:		described below:
	o "uses": an optional attribute instructing the LIS on how many		o "uses": an optional attribute instructing the LIS on how many
	times a URI may yield the location of the Target. This is a		times a URI may yield the location of the Target. This is a
	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
	form of location that the URI MUST return. This is an enumeration
	and may have a value of _geodetic_, _civic_, or _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,
	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.
	<createContext		<createContext
	xmlns="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">
	<lifeTime>7200</lifeTime>		<lifeTime>7200</lifeTime>
	</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
	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 two attributes used in
	the context creation, "uses", "snapshot", and "locationType" cannot		the context creation, "uses" and "snapshot" cannot be changed once a
	be changed once a context is created.		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.
	<updateContext		<updateContext
	xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns="urn:ietf:params:xml:ns:geopriv:held:context"
	id="uhvuhdbnuiehudbnvcujevuijeijcvij3">		id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
	<lifeTime>3600</lifeTime>		<lifeTime>3600</lifeTime>
	skipping to change at page 11, line 10 ¶		skipping to change at page 10, line 43 ¶
	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
	that a context has been destroyed.		that a context has been destroyed.
	locationType: The type of location information that can be acquired
	through URIs addressing the context. The LIS MUST report this
	value for all responses pertaining to a known and valid context.
	This value MAY be omitted when indicating that a context has been
	destroyed.
	expiry: The time at which the context will expire. After this time,		expiry: The time at which the context will expire. After this time,
	all location URIs that reference this context no longer work. The		all location URIs that reference this context no longer work. 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
	context. This attribute MUST be provided even when a "code" value		context. This attribute MUST be provided even when a "code" value
	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.
	<contextResponse		<contextResponse
	xmlns="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"
	expires="2007-11-01T13:30:00">		expires="2007-11-01T13:30:00">
	<locationUriSet>		<locationUriSet>
	<locationURI>		<locationURI>
	held://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4		held://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4
	</locationURI>		</locationURI>
	<locationURI>		<locationURI>
	sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769		sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769
	</locationURI>		</locationURI>
	</locationUriSet>		</locationUriSet>
	</contextResponse>		</contextResponse>
	Figure 4: contextResponse Example		Figure 4: contextResponse Example
	5.4. Context Errors		5.4. Context Errors
	When the LIS unable to perform the requested context operation it		When the LIS is unable to perform the requested context operation it
	need to inform the Target of this. It does this using a held error		need to inform the Target of this. It does this using a held error
	message. New codes are defined for context operation errors:		message. New codes are defined for context operation errors:
	o _badContextMessage_: The LIS was unable to understand the content		o _badContextMessage_: The LIS was unable to understand the content
	of the message. In general this will apply to context messages		of the message. In general this will apply to context messages
	containing extensions that the LIS does not understand.		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 _updateContextFailed_: The LIS was unable to updated the requested		o _updateContextFailed_: The LIS was unable to updated the requested
	context.		context.
	o _createContextFailed_: The LIS was unable to created the requested		o _createContextFailed_: The LIS was unable to created the requested
	context.		context.
	A Target implementing this specification MUST accept a any HELD error		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 as a LIS may not understand context messages. A LIS that		message as a LIS may not understand context messages. A LIS that
	does understand context messages is expected to return the error		does understand context messages is expected to return the error
	codes above unde the prescribed circumstances.		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="createContextFailed"
	message="locationType of Civic is not supported"/>		message="Snapshot is not supported"/>
	Figure 5: Example Error Message		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
	skipping to change at page 14, line 15 ¶		skipping to change at page 13, line 15 ¶
	6. XML Schema		6. XML Schema
	<?xml version="1.0"?>		<?xml version="1.0"?>
	<xs:schema		<xs:schema
	targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"		targetNamespace="urn:ietf:params:xml:ns:geopriv:held:context"
	xmlns:xs="http://www.w3.org/2001/XMLSchema"		xmlns:xs="http://www.w3.org/2001/XMLSchema"
	xmlns:heldCx="urn:ietf:params:xml:ns:geopriv:held:context"		xmlns:heldCx="urn:ietf:params:xml:ns:geopriv:held:context"
	xmlns:xml="http://www.w3.org/XML/1998/namespace"		xmlns:xml="http://www.w3.org/XML/1998/namespace"
	elementFormDefault="qualified" attributeFormDefault="unqualified">		elementFormDefault="qualified" attributeFormDefault="unqualified">
	<xs:simpleType name="locationType">
	<xs:restriction base="xs:token">
	<xs:enumeration value="any"/>
	<xs:enumeration value="civic"/>
	<xs:enumeration value="geodetic"/>
	</xs:restriction>
	</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="useType">		<xs:simpleType name="useType">
	<xs:union memberTypes="xs:positiveInteger">		<xs:union memberTypes="xs:positiveInteger">
	skipping to change at page 15, line 4 ¶		skipping to change at page 13, line 44 ¶
	<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"
	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:restriction base="xs:anyType">
	<xs:sequence>		<xs:sequence>
	<xs:element name="locationURI" type="xs:anyURI"		<xs:element name="locationURI" type="xs:anyURI"
	skipping to change at page 15, line 42 ¶		skipping to change at page 14, line 31 ¶
	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: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"
	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="xs:anyType">		<xs:restriction base="xs:anyType">
	skipping to change at page 22, line 26 ¶		skipping to change at page 21, line 26 ¶
	Guidelines for designing context extensions that provide		Guidelines for designing context extensions that provide
	functionality are described below.		functionality are described below.
	Two basic types of context data extension are envisioned. The first		Two basic types of context data extension are envisioned. The first
	consist of data provided by the Target to be consumed by the LIS; for		consist of data provided by the Target to be consumed by the LIS; for
	example information pertaining to PIDF-LO construction, usage-rules,		example information pertaining to PIDF-LO construction, usage-rules,
	and authorization policies. The second type of data consists of a		and authorization policies. The second type of data consists of a
	two way exchange between the Target and the LIS; for example		two way exchange between the Target and the LIS; for example
	exchanging location determination capabilities. Extensibility to the		exchanging location determination capabilities. Extensibility to the
	context scheme is to allow additional elements to be added to the		context scheme is to allow additional elements to be added to the
	context easily. The general idea is shown in Figure 8.		context easily. The general idea is shown in Figure 7.
	<hc:createContext		<hc:createContext
	xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context">		xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context">
	<lifeTime>7200</lifeTime>		<lifeTime>7200</lifeTime>
	<ex1:extension-1		<ex1:extension-1
	xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1">		xmlns:ex1="urn:ietf:params:xml:ns:geopriv:held:ex1">
	<ex1:value>7200</ex1:value>		<ex1:value>7200</ex1:value>
	</ex1:extension-1>		</ex1:extension-1>
	<extension-2 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"/>		<extension-2 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"/>
	<extension-3 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3"/>		<extension-3 xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3"/>
	.		.
	.		.
	.		.
	<extension-N xmlns="urn:ietf:params:xml:ns:geopriv:held:exN"/>		<extension-N xmlns="urn:ietf:params:xml:ns:geopriv:held:exN"/>
	</hc:createContext>		</hc:createContext>
	Figure 8: Create Context with Extensions		Figure 7: Create Context with Extensions
	When defining a context data extension it is necessary to ensure that		When defining a context data extension it is necessary to ensure that
	the LIS can provide an adequate response to the Target indicating		the LIS can provide an adequate response to the Target indicating
	acceptance or rejection of the data provided. This may be an		acceptance or rejection of the data provided. This may be an
	explicit OK or FAIL message within the extension namespace, it may be		explicit OK or FAIL message within the extension namespace, it may be
	an attribute associated with part of a larger data exchange, or it		an attribute associated with part of a larger data exchange, or it
	may result in the LIS failing to create the context at all.		may result in the LIS failing to create the context at all.
	Regardless, it is mandatory for a context data extension to provide		Regardless, it is mandatory for a context data extension to provide
	an indication of success or failure.		an indication of success or failure.
	<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"
	expires="2007-08-01T13:00:00">		expires="2007-08-01T13:00:00">
	<locationUriSet>		<locationUriSet>
	<locationURI>		<locationURI>
	held//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"
	skipping to change at page 23, line 34 ¶		skipping to change at page 22, line 33 ¶
	<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"/>
	<ex3:extension-3		<ex3:extension-3
	xmlns:ex3="urn:ietf:params:xml:ns:geopriv:held:ex3">		xmlns:ex3="urn:ietf:params:xml:ns:geopriv:held:ex3">
	<datum-3>data</datum-3>		<datum-3>data</datum-3>
	<stuff>guff in here for extension</stuff>		<stuff>guff in here for extension</stuff>
	</ex3:extension-3>		</ex3:extension-3>
	</hc:contextRresponse>		</hc:contextRresponse>
	Figure 9: LIS response to createContext		Figure 8: LIS response to createContext
	When defining information to be included in a context data extension		When defining information to be included in a context data extension
	consideration should be given to how that data can be removed from		consideration should be given to how that data can be removed from
	the context. In some cases it may be necessary to void the context		the context. In some cases it may be necessary to void the context
	on the LIS in order to remove information, but this SHOULD be treated		on the LIS in order to remove information, but this SHOULD be treated
	as a last resort and not used as the primary mechanism for removing		as a last resort and not used as the primary mechanism for removing
	data from the context.		data from the context.
	Appendix B. HELD Compliance to IETF Location Configuration Protocol		Appendix B. HELD Compliance to IETF Location Configuration Protocol
	Location Reference Requirements		Location Reference Requirements
	skipping to change at page 26, line 19 ¶		skipping to change at page 25, 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-04 (work in		draft-ietf-geopriv-http-location-delivery-09 (work in
	progress), January 2008.		progress), September 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-06 (work in		Requirements", draft-ietf-geopriv-l7-lcp-ps-08 (work in
	progress), November 2007.		progress), June 2008.
	[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-01 (work		Mechanism", draft-ietf-geopriv-lbyr-requirements-03 (work
	in progress), October 2007.		in progress), July 2008.
	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
	Otto-Hahn-Ring 6		Linnoitustie 6
	Munich, Bavaria 81739		Espoo 02600
	Germany		Finland
	Phone: +49 89 636 40390		Phone: +358 (50) 4871445
	Email: Hannes.Tschofenig@nsn.com		Email: Hannes.Tschofenig@gmx.net
	URI: http://www.tschofenig.com		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
	skipping to change at page 28, line 44 ¶		skipping to change at line 883 ¶
	attempt made to obtain a general license or permission for the use of		attempt made to obtain a general license or permission for the use of
	such proprietary rights by implementers or users of this		such proprietary rights by implementers or users of this
	specification can be obtained from the IETF on-line IPR repository at		specification can be obtained from the IETF on-line IPR repository at
	http://www.ietf.org/ipr.		http://www.ietf.org/ipr.
	The IETF invites any interested party to bring to its attention any		The IETF invites any interested party to bring to its attention any
	copyrights, patents or patent applications, or other proprietary		copyrights, patents or patent applications, or other proprietary
	rights that may cover technology that may be required to implement		rights that may cover technology that may be required to implement
	this standard. Please address the information to the IETF at		this standard. Please address the information to the IETF at
	ietf-ipr@ietf.org.		ietf-ipr@ietf.org.
	Acknowledgment
	Funding for the RFC Editor function is provided by the IETF
	Administrative Support Activity (IASA).
End of changes. 35 change blocks.
	87 lines changed or deleted		45 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/