< draft-winterbottom-geopriv-held-context-00.txt		draft-winterbottom-geopriv-held-context-01.txt >
	Geopriv J. Winterbottom		Geopriv J. Winterbottom
	Internet-Draft Andrew Corporation		Internet-Draft Andrew Corporation
	Intended status: Standards Track June 22, 2007		Intended status: Standards Track H. Tschofenig
	Expires: December 24, 2007		Expires: April 8, 2008 Nokia Siemens Networks
			M. Thomson
			Andrew Corporation
			October 6, 2007
	HELD Protocol Context Management Extensions		HELD Protocol Context Management Extensions
	draft-winterbottom-geopriv-held-context-00.txt		draft-winterbottom-geopriv-held-context-01.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 34 ¶		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 December 24, 2007.		This Internet-Draft will expire on April 8, 2008.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document describes a protocol extension for HELD enabling an		This document describes a protocol extension for the HTTP Enabled
	End-Point to manage stateful information on an LCS.		Location Delivery (HELD) protocol. It allows a Target to manage
			their location information on a Location Information Server (LIS)
			through the application of constraints invoked by accessing a
			location URI. Constraints described in this memo restrict how often
			location can be accessed through a location URI, how long the URI is
			valid for, and the type of location information returned when a
			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. Detailed Description . . . . . . . . . . . . . . . . . . . . . 5		3. What is a Context? . . . . . . . . . . . . . . . . . . . . . . 5
	4. Location URI and id Generation Rules . . . . . . . . . . . . . 9		4. Constraints . . . . . . . . . . . . . . . . . . . . . . . . . 6
	5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10		4.1. Limited Use URIs . . . . . . . . . . . . . . . . . . . . . 6
	6. Guidelines For Defining Context Data Extensions . . . . . . . 12		4.2. Snapshot URIs . . . . . . . . . . . . . . . . . . . . . . 7
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 13		4.3. Location Type URIs . . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		5. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 8
			5.1. Create Context Message . . . . . . . . . . . . . . . . . . 8
			5.2. Update Context Message . . . . . . . . . . . . . . . . . . 9
			5.3. Context Response Message . . . . . . . . . . . . . . . . . 10
			5.4. Context Error Messages . . . . . . . . . . . . . . . . . . 12
			5.5. Location URI and Context Identifier Generation Rules . . . 12
			6. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 14
			7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
			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 . . . . . . . 15		urn:ietf:params:xml:ns:geopriv:held:context . . . . . . . 19
	8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 15		8.2. XML Schema Registration . . . . . . . . . . . . . . . . . 19
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17		9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
	10. Normative References . . . . . . . . . . . . . . . . . . . . . 18		Appendix A. Context Extensions . . . . . . . . . . . . . . . . . 22
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19		Appendix B. HELD Compliance to IETF Location Configuration
	Intellectual Property and Copyright Statements . . . . . . . . . . 20		Protocol Location Reference Requirements . . . . . . 24
			10. Normative References . . . . . . . . . . . . . . . . . . . . . 26
			Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
			Intellectual Property and Copyright Statements . . . . . . . . . . 28
	1. Introduction		1. Introduction
	The HELD specification [I-D.ietf-geopriv-http-location-delivery]		The HTTP Enabled Location Delivery (HELD) protocol specification
	provides a set of features that can be used by an End-Point to		[I-D.ietf-geopriv-http-location-delivery] provides a set of features
	retrieve location information from an LCS. The basic HELD		that can be used by a Target to retrieve location information from a
	specification does this in a more or less stateless manner. There		Location Information Server (LIS). The basic HELD specification does
	are situations however, where the End-Point wants or requires		this in a more or less stateless manner, and when a location URI is
	explicit management of data in a stateful manner on the LCS. This		retrieved the Target has no way of controlling how the URI is used; a
	specification describes an extension to the HELD protocol to support		Location Recipient in pocession of the location URI can get the
	End-Point management of state information contained in a "context" on		Target's location until the URI expires. This basic mechanism may be
	the LCS.		reasonable in a limited set of applications, but is unacceptable in a
			broader range of applications. This position is highlighted in
	Information contained in a context relates to a specific End-Point.		[I-D.ietf-geopriv-lbyr-requirements] which describes requirements for
	One of the most critical pieces of functionality provided in this		constraints relating to location URIs. This specification provides
	specification is the ability to void a location URI. This is		support for these requirements in HELD.
	important, because without this functionality there is no way stop a
	third-party that has your location URI from obtaining your location.
	This condition will persist until the location URI expires. The
	extension defined in this specification changes this behaviour by
	providing the End-Point the means to create, update, and terminate a
	context on the LCS to which a specific location URI set is bound.
	Terminating the context therefore explicitly voids the location URI
	ending the ability of a third-party to locate the Target.
	In addition to context management constructs this document also
	provides a set of guidelines to be followed by designers of future
	context data extensions.
	2. Terminology		2. Terminology
	The key conventions and terminology used in this document are defined		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	as follows:		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
			document are to be interpreted as described in [RFC2119].
	This document reuses the terms Target, as defined in [RFC3693].		This document reuses the terms Target, as defined in [RFC3693].
	This document uses the term Location Configuration Server, LCS, as		This document uses the term Location Information Server (LIS) as the
	the node in the access network providing location information to an		node in the access network that provides location information about a
	end-point. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps].		Target. This term is also used in [I-D.ietf-geopriv-l7-lcp-ps].
	This document uses the term End-Point to refer to the device or host		3. What is a Context?
	requesting to which contextual information stored on the LCS applies.
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		A Location URI points to a LIS that is able to provide the location
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		of a specific Target. The LIS is able to map the URI to the location
	document are to be interpreted as described in [RFC2119].		of the Target inside its administrative domain. We call this mapping
			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.
	3. Detailed Description		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
			basic HELD specification the exiry time of the context is determined
			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
			able to create URIs for limited periods, or to terminate URIs for
			which it longer wishes its location to be returned. This
			specification provides explicit support for this functionality.
	An End-Device wishing to have a context created on the LCS includes a		4. Constraints
	<createContext> element in the <locationRequest>. Information that
	the End-Point wants in the context is included inside the
	<createContext> element. Extensibility to the context scheme is
	provided to allow additional elements to added to the context easily.
	The general idea is shown in Figure 1.
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">		Constraints restrict the ability of a Location Recipient to resolve a
	<locationType>locationURI</locationType>		location URI to location information. The constraints are selected
	<hcx:createContext		by the Target and they are provided to the LIS that maintains them
	hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		along with the context. A LIS, understanding this specification,
	hcx:lifeTime="7200">		receives constraints provided by the Target, and returns a set of
	<ex1:extension-1		URIs influenced by the constraints.
	ex1:xmlns="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"/>
	</hcx:createContext>
	</locationRequest>
	Figure 1: createContext Usage		A single Target may want to place different contraints on different
			references and hence may have multiple contexts on the LIS. The
			constraints describe what actions the LIS MUST take when a URI
			associated with the context is accessed. This document describes
			three basic constraints that a Target can use in comination for the
			same context. Once set, these rules remain in force of the life of
			the context.
	An LCS that understands this new element SHALL include a		4.1. Limited Use URIs
	<contextResponse> element in the corresponding heldRepsonse message.
	An LCS that does not understand this new element MUST ignore the
	element as per [I-D.ietf-geopriv-http-location-delivery]. The End-
	Point MUST assume that the LCS does not understand context related
	messages if it does not obtain a <contextResponse> element in the
	<heldResponse> message when a context was requested. Since it is
	impossible to predict in advance which elements and extensions the
	LCS will understand before sending them, a mechanism for the LCS to
	tell the End-Point which elements were understood and used is
	required by each context data extension. Guidelines for defining
	context data extensions are provided in Section 6.
	An LCS supporting the behaviour described in the previous section may		A limited use URI can only be accessed a fixed number of times to
	respond to the locationRequest of Figure 1 with a response similar to		yield the location of the Target. Each time the URI is used to
	Figure 2.		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.
	<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"		By setting the usage limit to 1, the Target is able to create a one-
	code="200" message="OK">		time-URI permitting a Location Recipient to obtain the Target's
			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.
	<locationUriSet expires="2007-08-01T13:00:00">		Not setting a usage limit provides similar semantics to the URI in
	<locationURI>		the base HELD specification, enabling a Location Recipient to
	https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o		continually obtain the Target's location until the URI expires due to
	</locationURI>		age.
	<locationURI>
	sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769
	</locationURI>
	</locationUriSet>
	<hcx:contextResponse		When an HTTP URI is assigned to a context, the limit is the number of
	hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		times that the URI can be accessed before the LIS returns an error.
	hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">		In the case of SIP it is the number of NOTIFY messages that are sent
	<ex1:extension-1 ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1"		prior to the LIS returning an error. Where a context supports both
	ex1:response="OK"/>		SIP and HTTP URIs it is the combination of URI accesses and NOTIFY
	<ex2:extension-2 ex2:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex2"		messages that constitutes the usage value, each time the Target's
	ex2:response="OK"/>		location is provided constitutes a usage.
	<ex3:extension-3		4.2. Snapshot URIs
	ex3:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex3">
	<ex3:datum-3>data</ex3:datum-3>
	<ex3:stuff>guff in here for extension</ex3:stuff>
	</ex3:extension-3>
	</hcx:contextRresponse>		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
			will always yield the same location. This is useful if, for example,
			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.
	</heldResponse>		4.3. Location Type URIs
	Figure 2: LCS response to createContext		A location type URI controls the form of location that can be
			accessed; This may be geodetic, civic, or both.
	The End-Point can update information associated with a context by		5. Protocol Details
	sending an <updateContext> element in a locationRequest message,
	along with the data that it wants changed in its context. Elements
	previously provided to the LCS but not included in the
	<updateContext> data set SHALL remain unchanged. The End-Point MUST
	include the "id" attribute that it received as part of the
	<contextResponse> with any <updateContext> request to clearly
	identify the changing context to the LCS. This is important because
	in some circumstances an End-Point may be behind a firewall or NAT so
	the LCS can't distinguish the End-Point creating the context from
	other devices behind the same NAT. The "id" makes this distinction
	possible.
	<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">		This specification introduces four new HELD messages, create context
	<locationType>any</locationType>		(<createContext>), update context (<updateContext>), context response
			(<contextResponse>), and context error (<contextError>). A LIS that
			does not understand this specification is expected to return a HELD
			_unsupportedMessage_ error code in a HELD error message.
	<hcx:updateContext		The specification assumes that the LIS was discovered as part of the
	hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		general HELD LIS discovery process. All messages are sent using the
	hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">		application/held+xml MIME type as defined in
	<ex1:extension-1		[I-D.ietf-geopriv-http-location-delivery].
	ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1">
	<ex1:value>3600</ex1:value>
	</ex1:extension-1>
	</hcx:updateContext>
	</locationRequest>		5.1. Create Context Message
	Figure 3: updateContext Usage		The Target creates a context on the LIS using a create context
			message. The basic create context message supports the constraints
			described in Section 4 and consist of three attributes and one
			element described below:
	In the example shown in Figure 3 the End-Point is updating the		o "uses": an optional attribute instructing the LIS on how many
	context created in Figure 1 so that the value associated with		times a URI may yield the location of the Target. This is a
	extensions-1 will be set to 3600 rather then the previous value of		positive integer, and has a default value of _unlimited_. The LIS
	7200. The response from the LCS is shown in Figure 4.		SHOULD support the Target specifying up to at least 100 uses.
	<heldResponse xmlns="urn:ietf:params:xml:ns:geopriv:held"		o "snapshot": an optional attribute instructing the LIS to take a
	code="200" message="OK">		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.
	<locationUriSet expires="2007-08-01T13:00:00">		o "locationType": an optional attribute instructing the LIS on the
	<locationURI>		form of location that URI MUST provide. This is an enumeration
	https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o		and may have a value of _geodetic_, _civic_, or _any_. If
	</locationURI>		unspecified by the Target the LIS will use a value of _any_. If
	<locationURI>		the Target specifies a location type that the LIS cannot provide,
	sips:357yc6s64ceyoiuy5ax3o@ls.example.com:9769		then the LIS MUST fail the context creation.
	</locationURI>
	</locationUriSet>
	<hcx:contextResponse		o "lifeTime": is a mandatory element that defines the maximum period
	hcx:xmlns="urn:ietf:params:xml:ns:geopriv:held:context"		in seconds that the LIS should keep the context for. The LIS MAY
	hcx:id="uhvuhdbnuiehudbnvcujevuijeijcvij">		create the context with a shorter life time than was requested,
	<ex1:extension-1 ex1:xmlns="urn:ietf:params:xml:ns:geopriv:held:ex1"		but the life time MUST NOT be longer than was requested.
	ex1:response="OK"/>
	</hcx:contextRresponse>
	</heldResponse>		<hc:createContext
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
			uses="10"
			snapshot="false"
			locationType="any">
			<hc:lifeTime>7200</hc:lifeTime>
			</hc:createContext>
	Figure 4: LCS response to updateContext		Figure 1: createContext Example
	The End-Point MUST include a locationType of locationURI in the		Figure 1 shows a create context message defining a context which:
	locationRequest, other location type MAY also be present. The LCS
	SHALL return the same location URI set in response to an
	<updateContext> as it did for a <createContext>. The LCS SHALL
	return the same "id" as was used in the request.
	The End-Point MAY include the "lifeTime" in an <updateContext>		o may be accessed 10 times
	request if it wishes to alter the lifetime of the context. Any
	change to lifetime SHALL be reflected in the expires attribute of the
	returned <locationUriSet>. If the "lifeTime" attribute is set to
	zero or is negative then the context SHALL expire immediately, and an
	empty <heldResponse> message SHALL be returned with a "code" of 200.
	When a context expires the LCS SHALL, immediately, delete all
	information associated with the context and void all location URIs
	associated with the context.
	An <updateContext> request containing an "id" that is not recognized		o will determine the location of the Target each time it is accessed
	by the LCS, or is for an expired context SHALL result in the LCS not
	returning a <contextResponse> in the subsequent heldResponse.
	4. Location URI and id Generation Rules		o will return the location in either geodetic or civic form
			depending on the request tot he URI
	A primary aim of this specification is to provide an End-Point with		o will be valid for 2 hours from the time of context creation
	the ability to void a location URI when it is associated with a
	context. To achieve this, a location URI generated as part of a
	context creation needs to be unique with in the scope of the LCS, and
	applicable only to that context. If the End-Point destroys a context
	and then subsequently creates a new one, URIs associated the new
	context MUST be different from those generated for the previous
	context.
	The context id provided by the LCS to the End-Point in the		5.2. Update Context Message
	<contextResponse> MUST be unique per context, and SHOULD be different
	from the identifier provided in any generated location URI. This
	latter constraint ensures that possession of a location URI does not
	automatically provide access and control over the internals of the
	context.
	A context id is generated by an LCS to uniquely identify a context.		A Target can change the life time of a context using an update
	The context id MUST NOT include any information that could be used to		context message. As stated in Section 4 the three attributes used in
	identify the Target or End-Point. Similarly, it MUST NOT be feasible		the context creation, "uses", "snapshot", and "locationType" cannot
	for a third-party to easily determine a context id by knowing the		be changed once a context is created.
	identity of the Target or End-Point. This implies that internal
	correlation (using a hash-table or similar) is the only method that
	the LCS can use to associate a context id with a particular End-
	Point.
	5. XML Schema		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
			including a context identifier that is provided to it by the LIS when
			the context is created.
			<hc:updateContext
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
			hc:id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
			<lifeTime>3600</lifeTime>
			</hc:updateContext>
			Figure 2: updateContext Life Time Change Example
			When a Target includes a life time element in an update context
			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
			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
			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
			life time value is set to less than 10 seconds.
			<hc:updateContext
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
			hc:id="uhvuhdbnuiehudbnvcujevuijeijcvij3">
			<lifeTime>0</lifeTime>
			</lhc:updateContext>
			Figure 3: updateContext Termination Example
			5.3. Context Response Message
			The LIS informs the Target about the outcome of context operations
			through the context response message. The LIS MUST always send a
			context response message to a Target in response to a create context
			or update context message when the outcome was successful. The
			context response message contains a "code" attribute indicating the
			performed operation, and the other attributes and elements indicating
			the state of the context.
			The "code" attribute is an enumerated type and has one of the
			following values:
			o _created_: The context was successfully created.
			o _destroyed_: The context was destroyed.
			o _updated_: The context was successfully updated.
			The following list details the other attributes are may be returned
			in a context response message.
			id: The identifier allocated to the context by the LIS. This
			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 and "id" in all context response messages.
			uses: The number of times that the context will yield the Target's
			location. The LIS MAY report either the original value, or the
			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
			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.
			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,
			all location URIs that reference this context no longer work. The
			LIS MUST report this value for all responses pertaining to a known
			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
			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
			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.
			<hc:contextResponse
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
			code="created"
			id="uhvuhdbnuiehudbnvcujevuijeijcvij4"
			uses="10"
			snapshot="false"
			locationType="any"
			expires="2007-11-01T13:30:00">
			<hc:locationUriSet>
			<hc:locationURI>
			https://lis.example.com:9768/357yc6s64ceyoiuy5ax3o4
			</hc:locationURI>
			<hc:locationURI>
			sips:357yc6s64ceyoiuy5ax3o4@lis.example.com:9769
			</hc:locationURI>
			</hc:locationUriSet>
			</hc:contextResponse>
			Figure 4: contextResponse Example
			5.4. Context Error Messages
			When the LIS unable to perform the requested context operation it
			need to inform the Target of this. It does this using a context
			error message. The context error message consists of a "errorCode"
			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
			message.
			o _unknownContext_: The LIS was unable to find the context.
			o _failed_: The LIS was unable to perform the requested operation.
			A Target implementing this specification MUST accept a HELD error
			message as a valid response to a create context or update context
			message.
			<hc:contextError
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
			code="failed"
			message="unable to update context">
			</hc:contextError>
			Figure 5: contextError With Message Example
			5.5. Location URI and Context Identifier Generation Rules
			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
			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
			identify only that context. If the Target destroys a context and
			subsequently creates a new one, URIs associated the new context MUST
			be different from those generated for the previous context.
			[I-D.ietf-geopriv-http-location-delivery] and
			[I-D.ietf-geopriv-lbyr-requirements] provide guideance on the
			creation and desired characteristcs of a location URI.
			The context identifier provided by the LIS to the Target in the
			context response message MUST be unique and MUST be different from
			the identifier provided in any location URI. This latter constraint
			ensures that possession of a location URI does not automatically
			provide access and control over the internals of the context.
			A context identifier is generated by a LIS to uniquely identify a
			context. It MUST NOT be feasible for a third-party to easily
			determine a context identifier by knowing the identity of the Target.
			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
	<?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:restriction base="xs:token">
			<xs:enumeration value="created"/>
			<xs:enumeration value="updated"/>
			<xs:enumeration value="destroyed"/>
			</xs:restriction>
			</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:union>
			<xs:simpleType>
			<xs:restriction base="xs:token">
			<xs;enumeration value="unlimited"/>
			</xs:restriction>
			</xs:simpleType>
			<xs:positiveInteger/>
			</xs:union>
			</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 "
			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="lifeTime" type="xs:integer"		<xs:attribute name="uses" type="heldCx:useType"
	use="optional"/>		use="optional" default="unlimited"/>
			<xs:attribute name="snapshot" type="xs:boolean"
			use="optional" default="false"/>
			<xs:attribute name="locationType" type="heldCx:locationType"
			use="optional" default="any"/>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</xs:complexType>
			<xs:complexType name="uriSetType">
			<xs:complexContent>
			<xs:sequence>
			<xs:element name="locationURI" type="xs:anyURI"
			maxOccurs="unbounded"/>
			</xs:sequence>
			</xs:complexContent>
			</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"
			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="id" type="xs:token"		<xs:attribute name="id" type="xs:token"
	use="required"/>		use="required"/>
			<xs:attribute name="expires" type="xs:dateTime"
			use="required"/>
			<xs:attribute name="uses" type="xs:positiveInteger"
			use="optional"/>
			<xs:attribute name="snapshot" type="xs:boolean"
			use="optional"/>
			<xs:attribute name="locationType" type="heldCx:locationType"
			use="optional"/>
			<xs:attribute name="code" type="heldCx:codeType"
			use="required"/>
			<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="heldCx:">
	<xs:sequence>		<xs:sequence>
			<xs:element name="lifeTime" type="xs:nonNegativeInteger "
			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:restriction>
			</xs:complexContent>
			</xs:complexType>
	<xs:attribute name="lifeTime" type="xs:integer"		<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"/>		use="optional"/>
			<xs:anyAttribute namespace="##any" processContents="lax"/>
	</xs:restriction>		</xs:restriction>
	</xs:complexContent>		</xs:complexContent>
	</xs:complexType>		</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 5: LCS response to updateContext		Figure 6: Context Management Schema
	6. Guidelines For Defining Context Data Extensions
	A context contains specific information about an End-Point and is
	stored on the LCS. It is impossible to predetermine all information
	that an End-Point may want or need stored in a context so the context
	control mechanisms need to be flexible to allow easy 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 End-Point to the LCS, but also acceptance and
	error indications from the LCS back to the End-Point. For example a
	context may be created with several extensions included, how does the
	LCS 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
	in this section.
	Two basic types of context data extension are envisioned. The first
	consist of data provided by the End-Point to be consumed by the LCS;
	for example information pertaining to PIDF-LO construction, usage-
	rules, and authorization policies. The second type of data consists
	of a two way exchange between the End-Device and the LCS; for example
	exchanging location determination capabilities.
	When defining a context data extension it is necessary to ensure that
	the LCS can provide an adequate response to the End-Point application
	indicating acceptance or rejection of the data provided. This may be
	an explicit OK or FAIL message within the extension namespace, or it
	may be an attribute associated with part of a larger data exchange.
	Either way it is mandatory for a context data extension to provide
	this functionality.
	When defining information to be included in a context data extension
	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
	on the LCS in order to remove information, but this SHOULD be treated
	as a last resort and not used as the primary mechanism for removing
	data from the context.
	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 End-Point to the LCS for		sensitivity of any data passed from the Target to the LIS for
	inclusion in a context. The second is the ability of the LCS to		inclusion in a context. The second is the ability of the LIS to
	contain the number of contexts that it will permit to exist for a		contain the number of contexts that it will permit to exist for a
	given End-Point address.		given Target address. Finally, there is a threat of Targets
			performing DoS attacks on the LIS by trying to create large numbers
			of short-lived contexts that result in the LIS expending resources in
			message processing.
	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 an End-Point and the LCS. This is deemed		TLS for exchanges between a Target and the LIS. This is deemed
	sufficiently secure to hide any contextual data from a would-be		adequate to provide confidentiality to any contextual data in
	eavesdropper while the data is in transit. The LCS implementation		transit. The LIS implementation and the operator of the LIS need to
	and the operator of the LCS need to take sufficient steps to ensure		take sufficient steps to ensure that active contextual data on the
	that active contextual data on the LCS is not readily available to		LIS is not readily available to anyone other than the Target. The
	anyone other than the End-Point that owns the data. The End-Point		Target MUST NOT provide any information to the LIS that it does not
	MUST not provide any information to the LCS that it does not want the		want the LIS to know or be able to use in some capacity associated
	LCS to know or be able to use in some capacity associated with		with determination or providing of the Target's location.
	determination or providing of the End-Point's location. The LCS
	SHALL not use any context information provided to it by an End-Point
	except to assist it with the determination and generation of location
	information associated with the End-Point.
	It is quite conceivable that an LCS will be required to provide		It is quite conceivable that a LIS will be required to provide
	location to end hosts residing behind a NAT; a DSL home router with 5		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		PCs attached is a good example this situation. In this case it is
	reasonable for each device to create its own context on the LCS, and		reasonable for each device to create its own context on the LIS, and
	for the LCS to treat each context individually even though the LCS		for the LIS to treat each context individually even though the LIS
	cannot make any other distinction between the end hosts; that is,		cannot make any other distinction between the end hosts; that is,
	they share a common IP address/identity from the LCS perspective. It		they share a common IP address/identity from the LIS perspective.
	may even be reasonable in some situations for a single device to want
	more than one context. This environment however opens the LCS to a
	type of denial of service attack through an overload on contexts. It
	is RECOMMENDED that an implementor of this specification include
	mechanisms to restrict to maximum number of contexts that can be
	created on the LCS by an individual End-Point. It is RECOMMENDED
	that an LCS operator impose limits on context creation such that it
	is restricted to a sustainable level.
	This specification provides the ability to for an End-Point to void a		Given the constraints that can be added to a context and the way that
	location URI which extends the End-Point's ability to enforce it		a Target might want to manage expiry separately, a Target may use
	rights to privacy. Using the mechanisms described in this memo an		multiple contexts as a way to isolate applications from each other.
	End-Point can create URIs with short validity periods, this restricts		For instance, a Target can create a context for each application so
	how long a third-party is able to obtain the location of the End-		that it can revoke access to its location information for each
	Point while still allowing the End-Point the convenience of using a		without affecting other applications' access. This environment,
	location reference. Using short-term location URIs in a carefully		however, opens the LIS to a type of denial of service attack through
	controlled manner may obviate the need for individual location		an overload of contexts. It is RECOMMENDED that an implementer of
	authorization policies on the LCS. This leads to reduced LCS		this specification include mechanisms to restrict to the maximum
	complexity and the amount of private information that the End-Point		number of contexts that can be created on the LIS by an individual
	need share with the LCS.		Target.
	The generation of context identifiers by the LCS is a critical		Using short-term location URIs in a carefully controlled manner may
			obviate the need for individual location authorization policies on
			the LIS. This leads to reduced LIS complexity and the amount of
			private information that the Target need share with the LIS. This
			specification provides the ability for a Target to cancel a location
			URI which extends the Target's ability to enforce its entitlement to
			privacy. Using the mechanisms described in this memo a target can
			create URIs with short validity periods; this restricts how long a
			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
	component to supporting the functionality described in this memo.		component to supporting the functionality described in this memo.
	The LCS MUST follow the rules described in Section 4 for generating		The LIS MUST follow the rules described in Section 5.5 for generating
	context identifiers.		context identifiers.
	8. IANA Considerations		8. 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		8.1. URN Sub-Namespace Registration for
	urn:ietf:params:xml:ns:geopriv:held:context		urn:ietf:params:xml:ns:geopriv:held:context
	skipping to change at page 16, line 8 ¶		skipping to change at page 20, line 8 ¶
	8.2. XML Schema Registration		8.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 5 of this document.		Figure 6 of this document.
	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.
			Appendix A. Context Extensions
			A context contains specific information about a Target and is stored
			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
			consist of data provided by the Target to be consumed by the LIS; for
			example information pertaining to PIDF-LO construction, usage-rules,
			and authorization policies. The second type of data consists of a
			two way exchange between the Target and the LIS; for example
			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 8.
			<hc:createContext
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context">
			<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 8: Create Context with Extensions
			When defining a context data extension it is necessary to ensure that
			the LIS can provide an adequate response to the Target indicating
			acceptance or rejection of the data provided. This may be an
			explicit OK or FAIL message within the extension namespace, it may be
			an attribute associated with part of a larger data exchange, or it
			may result in the LIS failing to create the context at all.
			Regardless, it is mandatory for a context data extension to provide
			an indication of success or failure.
			<hc:contextResponse
			xmlns:hc="urn:ietf:params:xml:ns:geopriv:held:context"
			code="created"
			id="uhvuhdbnuiehudbnvcujevuijeijcvij"
			uses="unlimited"
			snapshot="false"
			locType="any"
			expires="2007-08-01T13:00:00">
			<locationUriSet>
			<locationURI>
			https://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
			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 9: LIS response to createContext
			When defining information to be included in a context data extension
			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
			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
			data from the context.
			Appendix B. HELD Compliance to IETF Location Configuration Protocol
			Location Reference Requirements
			This section describes how HELD and this specification comply to the
			LCP location reference requirements stipulated in
			[I-D.ietf-geopriv-lbyr-requirements].
			High-level requirements for a location configuration protocol.
			C1. "Location URI support - LCP: The configuration protocol MUST
			support a location reference in URI form."
			COMPLY. HELD only provides location references in URI form.
			C2. "Location URI expiration: The LCP MUST support the ability to
			specify to the server, the length of time that a location URI
			will be valid."
			COMPLY. HELD with the context management extensions described
			in this document provide the Target the ability to specify
			expiry times for location URIs.
			C3. "Location URI cancellation: The LCP MUST support the ability to
			request a cancellation of a specific location URI."
			COMPLY. HELD with the context management extensions described
			in this document provide the Target the ability to void location
			URIs when required.
			C4. "Random Generated: The location URI MUST be hard to guess, i.e.,
			it MUST contain a cryptographically random component."
			COMPLY. The HELD specification and this document provide
			specific guidance on the security surrounding location URI
			generation.
			C5. "Identity Protection - LCP: The location URI MUST NOT contain
			any information that identifies the user, device or address of
			record within the URI form."
			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
			of a requested location URI being repeatedly reused."
			COMPLY. HELD with the context management extensions described
			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
			to request a 'one-time-use' location URI (e.g., via a reuse flag
			setting)."
			COMPLY. HELD with the context management extensions described
			in this document provide the Target the ability to specify how
			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		10. Normative References
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[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., "HTTP Enabled Location Delivery (HELD)",		Barnes, M., Winterbottom, J., Thomson, M., and B. Stark,
	draft-ietf-geopriv-http-location-delivery-00 (work in		"HTTP Enabled Location Delivery (HELD)",
	progress), June 2007.		draft-ietf-geopriv-http-location-delivery-02 (work in
			progress), September 2007.
	[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-02 (work in		Requirements", draft-ietf-geopriv-l7-lcp-ps-05 (work in
	progress), April 2007.		progress), September 2007.
	Author's Address		[I-D.ietf-geopriv-lbyr-requirements]
			Marshall, R., "Requirements for a Location-by-Reference
			Mechanism", draft-ietf-geopriv-lbyr-requirements-00 (work
			in progress), September 2007.
			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
	Email: james.winterbottom@andrew.com		Email: james.winterbottom@andrew.com
			URI: http://www.andrew.com/products/geometrix
			Hannes Tschofenig
			Nokia Siemens Networks
			Otto-Hahn-Ring 6
			Munich, Bavaria 81739
			Germany
			Phone: +49 89 636 40390
			Email: Hannes.Tschofenig@nsn.com
			URI: http://www.tschofenig.com
			Martin Thomson
			Andrew Corporation
			PO Box U40
			University of Wollongong, NSW 2500
			AU
			Phone: +61 242 212915
			Email: martin.thomson@andrew.com
			URI: http://www.andrew.com/products/geometrix
	Full Copyright Statement		Full Copyright Statement
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	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
End of changes. 72 change blocks.
	296 lines changed or deleted		648 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/