< draft-marshall-geopriv-lbyr-requirements-00.txt		draft-marshall-geopriv-lbyr-requirements-01.txt >
	GeoPriv R. Marshall, Ed.		GeoPriv R. Marshall, Ed.
	Internet-Draft TCS		Internet-Draft TCS
	Expires: August 9, 2007 February 5, 2007		Intended status: Standards Track March 4, 2007
			Expires: September 5, 2007
	Requirements for a Location-by-Reference Mechanism used in Location		Requirements for a Location-by-Reference Mechanism used in Location
	Configuration and Conveyance		Configuration and Conveyance
	draft-marshall-geopriv-lbyr-requirements-00		draft-marshall-geopriv-lbyr-requirements-01
	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 35 ¶
	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 9, 2007.		This Internet-Draft will expire on September 5, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines terminology and enumerates requirements for a		This document defines terminology and enumerates requirements for a
	location-by-reference approach to location configuration and		location-by-reference approach to location configuration and
	conveyance interactions useful for emergency call routing for voice-		conveyance interactions useful for emergency call routing for voice-
	over-IP (VoIP) and general Internet multimedia systems, where		over-IP (VoIP) and general Internet multimedia systems, where
	Internet protocols are used end-to-end.		Internet protocols are used end-to-end.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 4		2. Requirements Terminology . . . . . . . . . . . . . . . . . . . 5
	3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 5		3.1. Terms . . . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. Actors . . . . . . . . . . . . . . . . . . . . . . . . . . 5		4. Examples of various LRI Model . . . . . . . . . . . . . . . . 8
	3.3. Location . . . . . . . . . . . . . . . . . . . . . . . . . 5		5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 12
	4. Basic Actors . . . . . . . . . . . . . . . . . . . . . . . . . 7		6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
	5. High-Level Requirements . . . . . . . . . . . . . . . . . . . 9		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 11		8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 18
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . . 18
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 15		Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20
	10.2. Informative References . . . . . . . . . . . . . . . . . . 15		Intellectual Property and Copyright Statements . . . . . . . . . . 21
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 17
	Intellectual Property and Copyright Statements . . . . . . . . . . 18
	1. Introduction		1. Introduction
			This document identifies the individual requirements underlying how a
			Location-by-Reference (LbyR) mechanism is to be used over the
			Internet, applied to either a Conveyance protocol or to a
			Configuration protocol. The LbyR approach is in contrast to the
			Location-by-Value (LbyV) model, which uses a "location object" (e.g.,
			PIDF-LO) exclusively. Examples using the Location-by-Value method
			are beyond the scope of this document.
	A mechanism for either (or both) location configuration and location		A mechanism for either (or both) location configuration and location
	conveyance may rely on either a location-by-value approach,		conveyance may rely on either a location-by-value approach,
	containing and transporting location information along every leg of		containing and transporting location information along every leg of
	the signaling path, or alternatively, a different approach, using a		the signaling path, or alternatively, a different approach, using a
	location-by-reference technique, which may be used to reference a		location-by-reference technique, which may be used to reference a
	location with some identifier, and to de-reference the location when		location with some identifier, and to de-reference the location when
	needed for a location-based decision.		needed for a location-based decision.
	This document uses as a baseline condition, the primary example of an		[http://www.ietf.org/internet-drafts/
	emergency call, which includes a request for emergency services via a		draft-ietf-sip-location-conveyance-07.txt] For an application of LbyR
	SIP-enabled end device, connecting through the Internet to an IP-		Conveyance, we choose to use the example of SIP signaling within an
	enabled PSAP (Public Service Answering Point).		emergency services context, though we also talk about LbyR in a more
			general sense. In this case, a SIP user agent, or SIP proxy server
			acting on behalf of a user agent, to another user agent via the SIP
			protocol [RFC3261]. In place of the actual value for a "Location", a
			Location Reference ID (LRI) is used to represent the "value" of the
			location, stored in some Internet-connected host, which we call a
			location server.
			For a LbyR Configuration protocol mechanism, even for the emergency
			service context mentioned, many different protocol choices exist.
			These include DHCP, LLDP-MED, and several Layer 7 protocols being
			considered for standardization. Regardless of the variety of
			choices, the general concept of how LbyR is used for configuration,
			is not specific to any particular protocol choice.
			A Location which is referenced can be either Geographic location [RFC
			3693] (e.g., lat/lon), or a Civic location (e.g., street address).
			We reintroduce a few basic entities [RFC3693] into the Location-by-
			Reference discussion. These include a "target" as the entity whose
			location is being transmitted, (e.g., a user agent's (UA) location.
			A "using protocol", defined as how a "location server" transmits a
			"location reference identifier" to a "location recipient". Privacy
			of a target's location, with repect to identity is important to
			protect, hence all examples shown assume that any user identity
			associated with the target is not included with location.
			Location can be pushed from one host to another, as part of a
			signaling protocol, in order to be used for location-based routing
			(or other purposes, outside the scope here), or it can alternatively
			be queried via a client request to a server which provides location
			[ref. drafft-sip-conveyance- TBD]. In the case of LbyR Conveyance,
			the actual location (i.e., location object) never gets pushed along,
			but is replaced by a Location Reference Identifier. In the case of a
			client which queries a server for location, the query is either to
			obtain a Location Reference Identifier, or to obtain an actual
			Location (e.g., location object) based the input of an LRI in the
			query.
			The draft-sip-conveyance- document details how SIP proxies treat LbyV
			or LbyR scenarios for conveying location via the SIP protocol.
			Whereas location objects are readily consumable by the hosts that
			using protocols deliver to, a Location Reference ID must first go
			through a dereference step in order to be useful.
			In our SIP example, for LbyR, instead of having a content identifier
			(cid:) pointing to a location object within a SIP body, the LRI is
			carried in the Geolocation header of a SIP message which is used to
			get a location via a dereference.
			A common example use case is the "emergency services call" case,
			where an request for emergency services is initiated over the
			Internet via the SIP protocol (i.e., a '9-1-1' or '1-1-2' call). In
			order to route the call to the appropriate PSAP, the UA client
			location is required.
			This document uses as a baseline scenario, the example of an
			emergency call, where an request for emergency services is initiated
			over the Internet using the SIP protocol (e.g., a '9-1-1' or '1-1-2'
			call). In order to route the call to the appropriate PSAP, since
			PSAPs are divided regionally, the UA client location is required.
	We first define terminology in Section 3. The document then outlines		We first define terminology in Section 3. The document then outlines
	baseline requirements (Section 5), around the referencing and		baseline requirements (Section 5), around the referencing and
	dereferencing of location via some location identifier in lieu of the		dereferencing of location via some location identifier in lieu of the
	emergency caller's actual location.		emergency caller's actual location.
	Identification of the caller, as associated information to location		Identification of the caller, as associated information to location
	or location reference, either in conveyance or configuration, is out		or location reference, either in conveyance or configuration, is out
	of scope in this document.		of scope in this document.
	Location-by-reference is a mechanism which is in use in VoIP 9-1-1		Location-by-reference is a mechanism which is in use in VoIP 9-1-1
	systems at the time of this writing, and justified based on the		systems at the time of this writing, and justified based on the
	requirements listed in this document.		requirements listed in this document.
	2. Requirements Terminology		2. Requirements Terminology
	In this document, the key words "MUST", "MUST NOT", "REQUIRED",		In this document, the key words "MUST", "MUST NOT", "REQUIRED",
	"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",		"SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
	and "OPTIONAL" are to be interpreted as described in RFC 2119 [1],		and "OPTIONAL" in this document are to be interpreted as described in
	with the qualification that unless otherwise stated these words apply		RFC 2119 [RFC2119].
	to the design of the location-by-reference mechanism, and not its
	implementation or application.
	3. Terminology		3. Terminology
	3.1. Terms		3.1. Terms
	Location Reference Identifier (LRI): An identifier (could be of the		Several of the terms presented below are based on RFC3693, and in
	form of any URI) which is designed to represent a location object.		some cases, extended to include additional language to support the
			Location-by-Reference model.
			Dereference Protocol: A protocol which is used to query a Location
			server based on an LRI as input.
			Location Reference Identifier (LRI): An identifier (e.g., URI) which
			is a pointer to a target's location record on a remote host (e.g.,
			location server), and is used by a dereferencing protocol for
			retrieval of that specific location.
	Location Server (LS): A network host which is designed to store		Location Server (LS): A network host which is designed to store
	location and to provide that same location to appropriate location		location and to provide that same location to appropriate location
	client requests.		client requests. May also be referred to as a Location
			Information Server (LIS).
	Location-to Mapping Server (LMS): A network host which provides a
	URI mapping service based on an input location and service
	identifier.
	Call Server/Proxy (CS/P): A network host which plays the role of a		LoST Mapping Server (LMS): A network host which provides a URI
	SIP Proxy.		response based on input of a location and service identifier [ref.
			draft-ecrit-lost-].
	3.2. Actors		Using Protocol: A protocol that carries a Location Object or an
			Location Reference Identifier (i.e., LRI).
	de-reference protocol client: The term to describe the entity		Target: A person or other entity whose location is communicated by a
	requesting a Location Object in exchange for a Location Reference		Geopriv Location Object.
	Identifier provided.
	de-reference protocol server: The term to describe the entity		Location Recipient (LR): The entity that receives location
	providing a Location Object as an output based on a Location		information. It may have asked for this location explicitly (by
	Reference Identifier input.		sending a query containing an LRI to a location server), or it may
			receive this location asynchronously. Also may be referred to as
			a Dereference client within this document, in the context of the
			Location-by-Reference model.
	3.3. Location		Location Server (LS): The entity to which a LG publishes location
			objects, the recipient of queries from location receivers, and the
			entity that applies rules designed by the rule maker. Also may be
			referred to as a Dereference server within this document, in the
			context of the Location-by-Reference model.
	Location: A geographic identification assigned to a region or		Location: A geographic identification assigned to a region or
	feature based on a specific coordinate system, or by other precise		feature based on a specific coordinate system, or by other precise
	information such as a street number and name. It can be either a		information such as a street number and name. It can be either a
	civic or geographic location.		civic or geographic location.
	Civic location: A described location based on some reference system,		Civic location: A described location based on some reference system,
	such a jurisdictions or postal delivery. A street address is a		such a jurisdictions or postal delivery. A street address is a
	common example.		common example.
	skipping to change at page 7, line 5 ¶		skipping to change at page 8, line 5 ¶
	Location-by-Value: The mechanism of representing location either in		Location-by-Value: The mechanism of representing location either in
	conveyance protocols or configuration protocols as fully		conveyance protocols or configuration protocols as fully
	specified, (i.e., including the actual location value itself).		specified, (i.e., including the actual location value itself).
	Location-by-Reference: The mechanism of representing location either		Location-by-Reference: The mechanism of representing location either
	in conveyance protocols or configuration protocols as an		in conveyance protocols or configuration protocols as an
	identifier which refers to a fully specified location, (i.e.,		identifier which refers to a fully specified location, (i.e.,
	including a pointer to the actual location value itself).		including a pointer to the actual location value itself).
	4. Basic Actors		4. Examples of various LRI Model
	To support the referencing or de-referencing of a location, it is		To support the referencing or de-referencing of a location, it is
	appropriate to describe a diagram consisting of network elements		appropriate to describe a diagram consisting of network elements
	around which this might be done. These elements include, the UA		around which this might be done. These elements include, the UA
	(User Agent), CS/P (Call Server/Proxy), a LS (Location Server), and a		(User Agent), P (Proxy), LS (Location Server), and a UA at the PSAP
	PSAP UA.		(UA2).
	This section outlines which entities will be considered in the		This section outlines which entities will be considered in the
	referernce de-reference scenarios discussed.		referernce/dereference scenarios discussed.
	+-------+		<t>
	| | |-------------------------------		<figure anchor="LRI Indirection" title="LRI query/response - where
	| LMS |---|---------------- \		Target = Location Recipient.">
	| | |--- \ \		<artwork><![CDATA[
	+-------+ \ \ \
	\ \ \
	\ \ \
	\ \ \
	+-------+ +-------+ +-------+ +-------+
	| | | | | | | |
	| UA1 |------| P1 |------| P2 |------| UA2 |
	| | | | | | | |
	+-------+ +-------+ +-------+ +-------+
	| / / /
	| / / /
	| / / /
	+-------+ / / /
	| | |-- / /
	| LS |---|---------------- /
	| | |------------------------------
	+-------+
	Figure 1: Framework for referencing or de-referencing location in a		+--------+ +--------+
			| Target |<---------response w/LO-------| |
			| == | | LS |
			| LR |-----------query w/LRI------->| |
			+--------+ +--------+
			Figure 1: Framework for referencing or de-referencing location in a
	SIP session.		SIP session.
			Above figure shows simplest LRI interaction, when target happens to
			also be the Location Recipient [ref. RFC3693 terms]
			+--------+ +--------+ +--------+
			| | | | | |
			| Target |<----------acquire LO---------| LS |<--deref--| LR |
			| | | | LRI | |
			+--------+ +--------+ +--------+
			| |
			+----------------convey LRI--------------------------------->+
			Figure 2: Setup showing LRI indirection.
			The above interaction reduces to two basic interactions: 1. Location
			provision from LS/LIS to target by reference (LRI). 2. Location
			indirection by the LS/LIS, at the request of the Target. Location
			updates, are possible in either case.
			+--------+ +--------+ +--------+
			| | | | | |-------LO------+
			| Target |<........>| LG |--LI/LO-->| LS/DS | |
			| | | | | |<---LRI---+ |
			+--------+ +--------+ +--------+ | |
			| |
			| v
			+--------+ +--------+ +--------+
			| | | | | |
			| LRG |---LRI--->| LT |--LRI-->| LR/DC |
			| | | | | |
			+--------+ +--------+ +--------+
			Figure 3: General Setup - LG interaction.
			Definitions: Target, LG, LR, LI, LO as in RFC 3693. LRG = Location
			Reference Generator (creates reference) LT = Location Transmitter
			(one party to Conveyance Protocol) DS/DC = Dereference Server /
			Client Protocols: Dereference Protocol is between DS and DC
			Conveyance Protocol is between LT and LR
			+--------+
			| |
			+--------------| LS |-----------------------------------+
			| | | |
			| + -------+ |
			LCP ^ LDP
			| LDP |
			V V V
			+--------+ +--------+ +--------+ +--------+
			| | | | | | | |
			| UA1 |--------->| P1 |--------->| P2 |--------->| UA2 |
			| | | | | | | |
			+--------+ +--------+ +--------+ +--------+
			^
			LMP
			V
			+--------+
			| |
			| LMS |
			| |
			+--------+
			Figure 4: Example of a SIP call.
			Definitions: LS = Location Server (as in RFC 3693) LCP = Location
			Configuration Protocol LDP = Location Dereference Protocol LMP =
			Location Mapping Protocol Sequence: 1. UA1 acquires LRI from its LS
			(acting as LRG) 2. UA1 sends an INVITE to a service URN via P1 3.
			P1 dereferences the LRI and uses it to get a URI from the LMS 4. UA2
			may also wish to dereference the LRI, e.g., to get the current
			location of UA1.
	Figure 1 shows the interaction between the entities involved in the		Figure 1 shows the interaction between the entities involved in the
	call, as to how location is referenced and subsequently de-		call, as to how location is referenced and subsequently de-
	referenced. The figure proposes that location reference is conveyed		referenced. The figure proposes that location reference is conveyed
	from the endpoint-to-endpoint via each middlebox (SIP Proxy), and		from the endpoint-to-endpoint via each middlebox (SIP Proxy), and
	undergoes a de-referencing operation at each step. The figure also		undergoes a de-referencing operation at each step. The figure also
	depicts a LMS (Location-to-Mapping Server) element which is used to		depicts a LMS (Location-to-Mapping Server) element which is used to
	determine the next target destination, based on the de-referenced		determine the next target destination, based on the de-referenced
	location.		location.
	At the PSAP, the end device also receives a location reference, (as		At the PSAP, the end device also receives a location reference, (as
	skipping to change at page 9, line 10 ¶		skipping to change at page 12, line 10 ¶
	4. The PSAP, consistent with the figure, may choose to de-reference		4. The PSAP, consistent with the figure, may choose to de-reference
	the location identifier, once it is received, in order to view		the location identifier, once it is received, in order to view
	the location, and to request subsequent location-based actions.		the location, and to request subsequent location-based actions.
	5. High-Level Requirements		5. High-Level Requirements
	Below, we summarize high-level design requirements needed for a		Below, we summarize high-level design requirements needed for a
	location-by-reference mechanism.		location-by-reference mechanism.
	Rq1. Location Conveyance By Value (LbyV): The conveyance protocol		Rq1. Location Reference Identifier as a URI: The dereferencing
	MUST support the conveyance of location information in its fully-		protocol MUST support an LRI in URI form, and may support other
	contained form, i.e., a PIDF-LO. (I know this isn't a requirement		non-URI forms.
	for LbyR, but is included for balance.)
	Rq2. Location Conveyance By Reference (LbyR): The conveyance
	protocol MAY support the conveyance of a location information
	reference identifier, in the form of 'any URI', which can be used
	to de-reference the location into its fully-contained form, (e.g.,
	a PIDF-LO).
	Rq3. Location Conveyance Duality: The location conveyance protocol		Rq2. Dereference Protocol Confidentiality: The dereferencing
	MAY support both location value and location reference identifier		protocol MUST support mechanisms for encrypting messages sent
	in the same message.		between client (Location recipient) and server (Location server).
	Rq4. Private Location Reference Id.: The dereferencing protocol		Rq3. Dereference Protocol Transparancy: The dereferencing protocol
	MUST support the encryption of a location reference identifier.		MUST support the exchange of messages without encryption (i.e., in
			plaintext).
	Rq5. Public Location Reference Id.: The dereferencing protocol MAY		Motivation: In the case where encrypted message exchange is
	convey a location reference identifier in plaintext.		unsuccessful, there must be a way to try to dereference a location
			reference identifier with less restriction (e..g., in the
			emergency service case, where every call always needs answered).
	Rq6. Location Reference Expiry: There MUST exist, a location		Rq4. Location Reference Expiry: The dereference protocol MUST
	reference uri format that includes a specified, finite period of		support specification of a finite period of validity for the LRI.
	validity.
	Motivation: Location references are not intended to represent a		Motivation: Location references are not intended to represent a
	location forever, and the identifier eventually may need to be		location forever, and the identifier eventually may need to be
	recycled, or may be subject to a specific window of validity,		recycled, or may be subject to a specific window of validity,
	after which the location reference fails to yield a location, or		after which the location reference fails to yield a location, or
	the location is determined to be kept confidential. An expiry		the location is determined to be kept confidential. An expiry
	timer for a location reference ensures that the location reference		timer for a location reference ensures that the location reference
	becomes invalid based on configuration.		becomes invalid based on configuration.
	Rq7. de-reference Protocol Transport: The de-reference protocol MUST		Rq5. Dereference Protocol Transport: The de-reference protocol MUST
	support TCP/IP and MAY support UDP/IP.		support TCP/IP and MAY support UDP/IP.
	Rq8. LRI Distribution: The location reference standard MUST allow		Motivation: Practical, near-term deployment issues may make TCP/IP
	construction of location references that can be distributed to and		implementations unachievable.
	de-referenced by multiple parties, and MAY support references that
	are restricted to a single de-referencer"
	Rq9''. de-reference Protocol Authentication: The dereferencing		Rq6''. Dereference Protocol Authentication: The dereferencing
	protocol MUST support both client-side and server-side		protocol MUST support both client-side and server-side
	authentication.		authentication.
	Motivation: It is reasonable to expect implementations of		Motivation: It is reasonable to expect implementations of
	authentication to vary. Some implementations may choose to		authentication to vary. Some implementations may choose to
	support both client-side and server-side authentication, might		support both client-side and server-side authentication, might
	support one only, or may support neither.		support one only, or may support neither.
	Rq10. Location Privacy: The de-reference protocol MUST support the		Rq7. Location Privacy: The dereference protocol MUST support the
	application of privacy rules to the dissemination of a requested		application of privacy rules to the dissemination of a requested
	location object. The entity that receives requests through the		location object.
	de-reference protocol MUST obey all privacy rules that apply to a
	requested location object.
	Rq11. De-referenced PIDF-LO Result: The dereferencing of an LRI		Rq8. Dereferenced PIDF-LO Result: The dereferencing of an LRI MUST
	MUST result in a well-formed PIDF-LO.		result in a well-formed PIDF-LO.
	Motivation: This is in order to ensure adequate privacy rules can		Motivation: This is in order to ensure adequate privacy rules can
	be adhered to, since the PIDF-LO format comprises the necessary		be adhered to, since the PIDF-LO format comprises the necessary
	structures to maintain location privacy.		structures to maintain location privacy.
	Rq12. Expiry of de-referenced Location: The de-referenced location,
	in PIDF-LO format, MUST include a configurable expiry timer to
	signal the point after which the PIDF-LO contained location is no
	longer considered usable.
	Motivation: Once the location is de-referenced, it would be
	difficult to keep it from being passed around further 'as a plain
	old PIDF-LO', hence a timer expiry is specified. (This technique
	does not prevent would-be 'black-hats' from reusing the PIDF-LO,
	but provides some additional functionality within a proper use
	context.
	Rq13. De-reference Protocol Selection: Location by reference
	systems MUST support at least one, and MAY support multiple
	dereferencing protocols.
	6. Security Considerations		6. Security Considerations
	Threats and security requirements are discussed in a separate		Considerations for security to a Location-by-Reference model for the
	document document [11].		dereference protocol, include, 1. Privacy Privacy of the LRI itself
			Privacy of the dereferenced location object 2. Expiry Expiry of the
			LRI. Expiry of the dereferenced location object. 3. Theft Theft of
			a LRI. Theft of a dereferenced location object. 4. Replay/Reuse
			Replay of a stolen LRI to perform a dereference operation. Reuse
			using the dereference location object. 5. Impact of the two forms of
			location reference. Location provision from LIS by reference.
			Location indirection by the LIS, at the request of the Target. May
			also reference security considerations found within document
			[I-D.ietf-geopriv-l7-lcp-ps].
	7. IANA Considerations		7. IANA Considerations
	This document does not require actions by the IANA.		This document does not require actions by the IANA.
	8. Contributors		8. Contributors
	[TBD]		Andrew Newton, James Polk, Martin Thompson, Richard Barnes, Barbara
			Stark, James Winterbottom, Hannes Tschofenig
	The contributors can be reached at:		The contributors can be reached at:
	Name user@example.com		Name user@example.com
	9. Acknowledgments		9. Acknowledgments
	[TBD]		[TBD]
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	10.2. Informative References		10.2. Informative References
	[2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,		[I-D.hardie-ecrit-lost]
	Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:		Hardie, T., "LoST: A Location-to-Service Translation
	Session Initiation Protocol", RFC 3261, June 2002.		Protocol", draft-hardie-ecrit-lost-00 (work in progress),
			March 2006.
	[3] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A. van		[I-D.ietf-ecrit-requirements]
	Wijk, "User Requirements for the Session Initiation Protocol		Schulzrinne, H. and R. Marshall, "Requirements for
	(SIP) in Support of Deaf, Hard of Hearing and Speech-impaired		Emergency Context Resolution with Internet Technologies",
	Individuals", RFC 3351, August 2002.		draft-ietf-ecrit-requirements-12 (work in progress),
			August 2006.
	[4] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.		[I-D.ietf-ecrit-security-threats]
	Polk, "Geopriv Requirements", RFC 3693, February 2004.		Taylor, T., "Security Threats and Requirements for
			Emergency Call Marking and Mapping",
			draft-ietf-ecrit-security-threats-03 (work in progress),
			July 2006.
	[5] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host		[I-D.ietf-geopriv-dhcp-civil]
	Configuration Protocol Option for Coordinate-based Location		Schulzrinne, H., "Dynamic Host Configuration Protocol
	Configuration Information", RFC 3825, July 2004.		(DHCPv4 and DHCPv6) Option for Civic Addresses
			Configuration Information",
			draft-ietf-geopriv-dhcp-civil-09 (work in progress),
			January 2006.
	[6] Peterson, J., "Common Profile for Instant Messaging (CPIM)",		[I-D.ietf-geopriv-l7-lcp-ps]
	RFC 3860, August 2004.		Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7
			Location Configuration Protocol; Problem Statement and
			Requirements", draft-ietf-geopriv-l7-lcp-ps-00 (work in
			progress), January 2007.
	[7] Schulzrinne, H., "The tel URI for Telephone Numbers", RFC 3966,		[I-D.ietf-sipping-toip]
	December 2004.		Wijk, A. and G. Gybels, "Framework for real-time text over
			IP using the Session Initiation Protocol (SIP)",
			draft-ietf-sipping-toip-07 (work in progress),
			August 2006.
	[8] Hellstrom, G. and P. Jones, "RTP Payload for Text		[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston,
	Conversation", RFC 4103, June 2005.		A., Peterson, J., Sparks, R., Handley, M., and E.
			Schooler, "SIP: Session Initiation Protocol", RFC 3261,
			June 2002.
	[9] Peterson, J., "A Presence-based GEOPRIV Location Object		[RFC3351] Charlton, N., Gasson, M., Gybels, G., Spanner, M., and A.
	Format", RFC 4119, December 2005.		van Wijk, "User Requirements for the Session Initiation
			Protocol (SIP) in Support of Deaf, Hard of Hearing and
			Speech-impaired Individuals", RFC 3351, August 2002.
	[10] Schulzrinne, H. and J. Polk, "Communications Resource Priority		[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and
	for the Session Initiation Protocol (SIP)", RFC 4412,		J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
	February 2006.
	[11] Taylor, T., "Security Threats and Requirements for Emergency		[RFC3825] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host
	Call Marking and Mapping", draft-ietf-ecrit-security-threats-03		Configuration Protocol Option for Coordinate-based
	(work in progress), July 2006.		Location Configuration Information", RFC 3825, July 2004.
	[12] Schulzrinne, H. and R. Marshall, "Requirements for Emergency		[RFC3860] Peterson, J., "Common Profile for Instant Messaging
	Context Resolution with Internet Technologies",		(CPIM)", RFC 3860, August 2004.
	draft-ietf-ecrit-requirements-12 (work in progress),
	August 2006.
	[13] Hardie, T., "LoST: A Location-to-Service Translation Protocol",		[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
	draft-hardie-ecrit-lost-00 (work in progress), March 2006.		RFC 3966, December 2004.
	[14] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4		[RFC4103] Hellstrom, G. and P. Jones, "RTP Payload for Text
	and DHCPv6) Option for Civic Addresses Configuration		Conversation", RFC 4103, June 2005.
	Information", draft-ietf-geopriv-dhcp-civil-09 (work in
	progress), January 2006.
	[15] Wijk, A. and G. Gybels, "Framework for real-time text over IP		[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object
	using the Session Initiation Protocol (SIP)",		Format", RFC 4119, December 2005.
	draft-ietf-sipping-toip-07 (work in progress), August 2006.
			[RFC4412] Schulzrinne, H. and J. Polk, "Communications Resource
			Priority for the Session Initiation Protocol (SIP)",
			RFC 4412, February 2006.
	Author's Address		Author's Address
	Roger Marshall (editor)		Roger Marshall (editor)
	TeleCommunication Systems, Inc.		TeleCommunication Systems, Inc.
	2401 Elliott Avenue		2401 Elliott Avenue
	2nd Floor		2nd Floor
	Seattle, WA 98121		Seattle, WA 98121
	US		US
End of changes. 50 change blocks.
	163 lines changed or deleted		303 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/