< draft-ietf-sip-location-conveyance-06.txt		draft-ietf-sip-location-conveyance-07.txt >
	SIP Working Group James Polk		SIP Working Group James Polk
	Internet Draft Cisco Systems		Internet Draft Cisco Systems
	Expiration: July 2nd, 2007 Brian Rosen		Expiration: Aug 12th, 2007 Brian Rosen
	NeuStar		Intended Status: Standards Track NeuStar
	Session Initiation Protocol Location Conveyance		Session Initiation Protocol Location Conveyance
	draft-ietf-sip-location-conveyance-06.txt		draft-ietf-sip-location-conveyance-07.txt
	Jan 2nd, 2007		Feb 12th, 2007
	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 36 ¶		skipping to change at page 1, line 36 ¶
	at any time. It is inappropriate to use Internet-Drafts as		at any time. It is inappropriate to use Internet-Drafts as
	reference material or to cite them other than as "work in		reference material or to cite them other than as "work in
	progress."		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 July 2nd, 2007.		This Internet-Draft will expire on August 12th, 2007.
	Copyright Notice		Copyright Notice
	Copyright (C) The IETF Trust (2007).		Copyright (C) The IETF Trust (2007).
	Abstract		Abstract
	This document defines an extension to the Session Initiation		This document defines an extension to the Session Initiation
	Protocol (SIP) to convey geographic location information from one		Protocol (SIP) to convey geographic location information from one
	SIP entity to another SIP entity. The extension covers end to end		SIP entity to another SIP entity. The extension covers end to end
	skipping to change at page 2, line 48 ¶		skipping to change at page 2, line 48 ¶
	Appendix B. Changes from Prior Versions . . . . . . . . . . 29		Appendix B. Changes from Prior Versions . . . . . . . . . . 29
	Intellectual Property and Copyright Statements . . . . . . . 34		Intellectual Property and Copyright Statements . . . . . . . 34
	1. Introduction		1. Introduction
	This document describes how Location can be "conveyed" (that is,		This document describes how Location can be "conveyed" (that is,
	sent on the Internet) from a SIP user agent, or in some		sent on the Internet) from a SIP user agent, or in some
	circumstances a proxy server acting on behalf of a user agent, to		circumstances a proxy server acting on behalf of a user agent, to
	another entity using the SIP [RFC3261] protocol. Here "Location" is		another entity using the SIP [RFC3261] protocol. Here "Location" is
	a description of the physical geographical area where a User Agent		a description of the physical geographical area where a User Agent
	currently exists. We use the term "conveyance" to distinguish other		currently exists. This document uses the term "conveyance" to
	circumstances when a location is used such as how the entity		describe scenarios in which a SIP user agent client (UAC) is telling
	conveying location using this extension determined where the		or informing a user agent server (UAS) where the UAC is. This is
	location was (using, for example, an Assisted GPS mechanism) or a		different from a UAC asking or seeking the location of where the UAS
	protocol by which the entity acquired the location it is conveying		is. Conveyance is a push model, where seeking is a pull model, and
	from another entity.		therefore not discussed here.
	Geographic location in the IETF is discussed in RFC 3693 (Geopriv		Geographic location in the IETF is discussed in RFC 3693 (Geopriv
	Requirements) [RFC3693]. It defines a "target" as the entity whose		Requirements) [RFC3693]. It defines a "target" as the entity whose
	location is being transmitted, in this case, it is the user agent's		location is being transmitted, in this case, it is the user agent's
	(UA) location. A [RFC3693] "using protocol" defines how a "location		(UA) location. A [RFC3693] "using protocol" defines how a "location
	server" transmits a "location object" to a "location recipient"		server" transmits a "location object" to a "location recipient"
	while maintaining the contained privacy intentions of the target		while maintaining the contained privacy intentions of the target
	intact. This document describes the extension to SIP for how it		intact. This document describes the extension to SIP for how it
	complies with the using protocol requirements, where the location		complies with the using protocol requirements, where the location
	server is a User Agent or Proxy Server and the location recipient is		server is a User Agent or Proxy Server and the location recipient is
	another User Agent or Proxy Server.		another User Agent or Proxy Server.
	Location can be transmitted by-value or by-reference. The "value"		Location can be transmitted by-value or by-reference. The "value"
	used in this document is a location object as described in		in this SIP extension is in the form of a Presence Information Data
	[RFC4119], that is, a PIDF-LO. Location-by-value refers to a user		Format - Location Object, or PIDF-LO, as described in [RFC4119]. A
	agent including a PIDF-LO as a body part of a SIP message, sending		PIDF-LO is an XML Schema specifically for carrying geographic
	that location object to another SIP element. Location-by-reference		location of a thing. Location-by-value refers to a user agent
			including a PIDF-LO as a body part of a SIP message, sending that
			location object to another SIP element. Location-by-reference
	refers to a user agent or proxy server including a URI in a SIP		refers to a user agent or proxy server including a URI in a SIP
	message which can be exchanged by a location recipient for a		message which can be exchanged by a location recipient for a
	location object, in the form of a PIDF-LO.		location object, in the form of a PIDF-LO.
	As recited in RFC3693, location often must be kept private. The		As recited in RFC 3693, location often must be kept private. The
	location object (PIDF-LO) contains rules which are binding on the		location object (PIDF-LO) contains rules which are binding on the
	location recipient and controls onward distribution and retention of		location recipient and controls onward distribution and retention of
	the location. This document describes the security and privacy		the location. This document describes the security and privacy
	considerations that must be applied to location conveyed with SIP.		considerations that must be applied to location conveyed with SIP.
	Often, location is sent from the User Agent Client to the User Agent		Often, location is sent from the User Agent Client to the User Agent
	Server, or vice versa for purposes that are beyond the scope of this		Server, or vice versa for purposes that are beyond the scope of this
	document. Another use for location is location-based routing of a		document. Another use for location is location-based routing of a
	SIP request, where the choice of the next hop (and usually, the		SIP request, where the choice of the next hop (and usually, the
	outgoing Request URI) is determined by the location of the UAC which		outgoing Request URI) is determined by the location of the UAC which
	is in the message by-value or by-reference. This document describes		is in the message by-value or by-reference. This document describes
	how location may be conveyed from the UAC, or a proxy acting on its		how location may be conveyed from the UAC, or a proxy acting on its
	behalf, to a routing proxy. How the location is actually used to		behalf, to a routing proxy. How the location is actually used to
	determine the next hop or Request-URI is beyond the scope of this		determine the next hop or Request-URI is beyond the scope of this
	document.		document.
	The Geolocation header is introduced to signify that location is		The Geolocation header is introduced to signify that location is
	included in a SIP message to provide either a content identifier		included in a SIP message to provide either a content identifier
	(cid:) pointer to the body part containing the UAs PIDF-LO, or a		(cid:) pointer to the body part containing the UA's PIDF-LO, or a
	location-by-reference URI that may subsequently be "dereferenced" by		location-by-reference URI that may subsequently be "dereferenced" by
	a using protocol (which may be SIP or another protocol).		a using protocol (which may be SIP or another protocol).
	In this document, we frequently refer to the "emergency case". This		In this document, we frequently refer to the "emergency case". This
	refers to a specific, important use of sip location conveyance where		refers to a specific, important use of sip location conveyance where
	the location of the caller is used to determine which Public Safety		the location of the caller is used to determine which Public Safety
	Answering Point (PSAP) should receive an emergency call request for		Answering Point (PSAP) should receive an emergency call request for
	help (e.g. a call to 1-1-2 or 9-1-1). This is an example of		help (e.g. a call to 1-1-2 or 9-1-1). This is an example of
	location-based routing. The location conveyed is also used by the		location-based routing. The location conveyed is also used by the
	PSAP to dispatch first responders to the caller's location. There		PSAP to dispatch first responders to the caller's location. There
	are special security considerations which make the emergency case		are special security considerations which make the emergency case
	unique, compared to a normal location conveyance within SIP.		unique, compared to a normal location conveyance within SIP.
	This document is intended to become a standards track RFC.
	2. Conventions used in this document		2. Conventions used in this document
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and		NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and
	"OPTIONAL" in this document are to be interpreted as described		"OPTIONAL" in this document are to be interpreted as described
	in [RFC2119].		in [RFC2119].
	3. Mechanisms		3. Mechanisms
	3.1 Overview of SIP Location Conveyance		3.1 Overview of SIP Location Conveyance
	skipping to change at page 6, line 6 ¶		skipping to change at page 6, line 5 ¶
	geoloc-param = "inserted-by" EQUAL geoloc-inserter		geoloc-param = "inserted-by" EQUAL geoloc-inserter
	/ "message-routed-on-this-uri"		/ "message-routed-on-this-uri"
	/ generic-param ; (from RFC 3261)		/ generic-param ; (from RFC 3261)
	geoloc-inserter = "endpoint" / "server"		geoloc-inserter = "endpoint" / "server"
	/ gen-value ; (from RFC 3261)		/ gen-value ; (from RFC 3261)
	The cid-url is defined in [RFC2392] to locate message body		The cid-url is defined in [RFC2392] to locate message body
	parts. This URI MUST be present if location is by-value in a		parts. This URI MUST be present if location is by-value in a
	message.		message.
	sip-URI, sips-URI and absoluteURI are defined according to RFC3261.		sip-URI, sips-URI and absoluteURI are defined according to RFC 3261.
	The pres-URI is defined in RFC 3859 [RFC3859].		The pres-URI is defined in RFC 3859 [RFC3859].
	Other protocols used in the Location URI MUST be reviewed against		Other protocols used in the Location URI MUST be reviewed against
	the RFC3693 criteria for a using protocol.		the RFC 3693 criteria for a using protocol.
	This document defines the Geolocation header as valid in the		This document defines the Geolocation header as valid in the
	following SIP requests:		following SIP requests:
	INVITE [RFC3261],		INVITE [RFC3261],
	REGISTER [RFC3261],		REGISTER [RFC3261],
	OPTIONS [RFC3261],		OPTIONS [RFC3261],
	UPDATE [RFC3311],		UPDATE [RFC3311],
	MESSAGE [RFC3428],		MESSAGE [RFC3428],
	SUBSCRIBE [RFC3265], and		SUBSCRIBE [RFC3265], and
	NOTIFY [RFC3265]		NOTIFY [RFC3265]
	Use of the header in BYE, INFO and REFER Methods are allowed,		Use of the header in BYE, INFO and REFER Methods are allowed,
	although no purpose is known. Conveying location in a CANCEL, BYE,		although no purpose is known. Conveying location in a CANCEL, BYE,
	ACK or PRACK is not defined. Discussing location using the PUBLISH		ACK or PRACK is not defined. Discussing location using the PUBLISH
	Request Method out of scope for this document.		Request Method out of scope for this document.
	The following table extends the values in Table 2&3 of RFC3261		The following table extends the values in Table 2&3 of RFC 3261
	[RFC3261].		[RFC3261].
	Header field where proxy INV ACK CAN BYE REG OPT PRA		Header field where proxy INV ACK CAN BYE REG OPT PRA
	----------------------------------------------------------------		----------------------------------------------------------------
	Geolocation Rr ar o - - o o o -		Geolocation Rr ar o - - o o o -
	Header field where proxy SUB NOT UPD MSG REF INF PUB		Header field where proxy SUB NOT UPD MSG REF INF PUB
	----------------------------------------------------------------		----------------------------------------------------------------
	Geolocation Rr ar o o o o o o -		Geolocation Rr ar o o o o o o -
	Table 1: Summary of the Geolocation Header		Table 1: Summary of the Geolocation Header
	The Geolocation header MAY be included in one of the above messages		The Geolocation header MAY be included in one of the above messages
	by a User Agent. A proxy MAY add the Geolocation header, but MUST		by a User Agent. A proxy MAY add the Geolocation header, but MUST
	NOT modify the contents of an existing Geolocation header.		NOT modify the contents of an existing Geolocation header.
	[RFC3261] states message bodies cannot be added by proxies.		[RFC3261] states message bodies cannot be added by proxies.
	Therefore, a Geolocation header added by a proxy MUST specify		Therefore, a Geolocation header added by a proxy MUST specify
	location-by-reference.		location-by-reference.
	Entities receiving location information MUST honor the usage element		Entities receiving location information MUST honor the usage element
	rules per RFC4119. Such entities MUST NOT alter the rule set.		rules per RFC 4119. Such entities MUST NOT alter the rule set.
	3.3 424 (Bad Location Information) Response Code		3.3 424 (Bad Location Information) Response Code
	If a UAS or SIP intermediary detects an error in a request message		If a UAS or SIP intermediary detects an error in a request message
	specific to the location information supplied by-value or		specific to the location information supplied by-value or
	by-reference, a new 4XX level error is created here to indicate a		by-reference, a new 4XX level error is created here to indicate a
	problem with the location in the request message. This document		problem with the location in the request message. This document
	creates and IANA registers the new error code:		creates and IANA registers the new error code:
	424 (Bad Location Information)		424 (Bad Location Information)
	skipping to change at page 7, line 25 ¶		skipping to change at page 7, line 24 ¶
	location information before attempting a new request that includes		location information before attempting a new request that includes
	location. There is no cross-transaction awareness expected by either		location. There is no cross-transaction awareness expected by either
	the UAS or SIP intermediary as a result of this error message.		the UAS or SIP intermediary as a result of this error message.
	More resolution of the error for which the 424 was generated MAY be		More resolution of the error for which the 424 was generated MAY be
	included in a Warning header [RFC3261] with new, IANA registered,		included in a Warning header [RFC3261] with new, IANA registered,
	location specific warning values (see Section 3.4).		location specific warning values (see Section 3.4).
	The new 424 (Bad Location Information) error code is IANA registered		The new 424 (Bad Location Information) error code is IANA registered
	in Section 9 of this document. An initial set of location error		in Section 9 of this document. An initial set of location error
	codes are in [ID-ERROR].		Warning codes are in Section 3.4 of this document.
	3.4 New Warning Codes for Location Error Granularity		3.4 New Warning Codes for Location Error Granularity
	As discussed in Section 3.3, more granular error codes, specific to		As discussed in Section 3.3, more granular error codes, specific to
	location errors within a received message, are required if the UAC		location errors within a received message, are required if the UAC
	is to know what was wrong with the original request. The Warning		is to know what was wrong with the original request. The Warning
	header will be used to convey such error conditions within the 424		header will be used to convey such error conditions within the 424
	(Bad Location Information) response. Rather than depleting the		(Bad Location Information) response. Rather than depleting the
	remaining available 3XX codes, codes 700 through 740 will be		remaining available 3XX codes, codes 700 through 740 will be
	designated for Location warnings. Additions to this		designated for Location warnings. Additions to this
	IANA registration range for location codes require an RFC.		IANA registration range for location codes require an RFC.
	Warning has the advantage of including the node ID in the header,		Warning has the advantage of including the node ID in the header,
	meaning the ID of the entity that sent this response. This can		meaning the ID of the entity that sent this response. This can be
	useful for troubleshooting.		useful for troubleshooting.
	The Warning header allows for multiple warning codes be returned in		The Warning header allows for multiple warning codes be returned in
	the same response. If a location-by-reference is sent and the		the same response. If a location-by-reference is sent and the
	supplied scheme is not desired or cannot be processed, but more than		supplied scheme is not desired or cannot be processed, but more than
	one other scheme can be, the 424 response can list more than one		one other scheme can be, the 424 response can list more than one
	code from the 720-724 range in the response. The UAC may		code from the 720-724 range in the response. The UAC may
	subsequently retry the operation with one of the schemes supported		subsequently retry the operation with one of the schemes supported
	or desired by the recipient.		or desired by the recipient.
	To illustrate this, here is an example of Alice including		To illustrate this, here is an example of Alice including
	location-by-reference using an HTTP schema. Bob cannot dereference		location-by-reference using an HTTP schema. Bob cannot dereference
	using HTTP, but can dereference using SIP, SIPS, and PRES:		using HTTP, but can dereference using SIP, SIPS, and PRES. An
			example of this transaction, with a 424 (Bad Location Information)
			response, including a Warning header, would be in here in Figure 1.
	Alice Bob		Alice Bob
	| |		| |
	| Request w/ Location |		| Request w/ Location |
	| using http schema |		| using http schema |
	|----------------------------------->|		|----------------------------------->|
	| |		| |
	| |		| |
	| 424 (Bad Location Information) |		| 424 (Bad Location Information) |
	| with Warning header containing |		| with Warning header containing |
	| 720 (SIP), 721 (SIPS), 722 (PRES) |		| 720 (SIP), 721 (SIPS), 722 (PRES) |
	|<-----------------------------------|		|<-----------------------------------|
	| |		| |
			Figure 1. Basic Transaction with Location Error
			The following subsections provide an initial list of location
			specific granular Warning codes for a 424 (Bad Location Information)
			response.
	3.4.1 Warning code 701 Location Format Not Supported		3.4.1 Warning code 701 Location Format Not Supported
	A Warning header with the code 701 "Location Format not supported"		A Warning header with the code 701 "Location Format not supported"
	means the location format supplied in the request, by-value or		means the location format supplied in the request, by-value or
	by-reference, was not supported. This cause means the recipient		by-reference, was not supported. This cause means the recipient
	understood that location was included in the message, but the format		understood that location was included in the message, but the format
	is not supported. Perhaps the format was a freeform text format or		is not supported. Perhaps the format was a freeform text format or
	data-URL and the recipient only understood location in RFC4119		data-URL and the recipient only understood location in RFC 4119
	PIDF-LO format (civic or geo). If a more specific Warning code is		PIDF-LO format (civic or coordinate). If a more specific Warning
	available, it MUST be used. For example, if the format is		code is available, it MUST be used. For example, if the format is
	understood, but not desired, a 702 or 703 Warning header SHOULD be		understood, but not desired, a 702 or 703 Warning header should be
	returned. The same applies to a location recipient that only		returned in a 424 response, depending on which location format is
			desired. The same applies to a location recipient that only
	understands one format and did not receive that format. For example,		understands one format and did not receive that format. For example,
	if a message containing geo formatted location arrives but the		if a message containing coordinate formatted location arrives but
	recipient only can process civic formatted location a 703 Warning		the recipient only can process civic formatted location, a 703
	header should be returned in a 424 response.		Warning header should be returned in a 424 response.
	Recommended warn-text: Location format not supported		Recommended warn-text: Location format not supported
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 701 alice.example.com "Location Format not supported"		Warning: 701 alice.example.com "Location Format not supported"
	3.4.2 Warning code 702 Geo-location Format Desired Instead		3.4.2 Warning code 702 Coordinate-location Format Desired Instead
	A Warning header with the code 702 "Geo-location Format Desired"		A Warning header with the code 702 "Coordinate-location Format
	means the location format supplied in the request (probably		Desired" means the location format supplied in the request (probably
	formatted in civic), by-value or by-reference, was understood and		formatted in civic), by-value or by-reference, was understood and
	supported, but that the recipient, or an application on the		supported, but that the recipient, or an application on the
	recipient prefers, or can only process location in the geo-location		recipient prefers, or can only process location in the
	format.		coordinate-location format.
	A typical reaction to receiving this Warning code is to resend the		A typical reaction to receiving this Warning code is to resend the
	original message with location formatted in geo instead.		original message with location formatted in coordinate instead.
	Recommended warn-text: Geo-location Format Desired		Recommended warn-text: Coordinate-location Format Desired
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 702 node_alice.example.com "Geo-location Format Desired"		Warning: 702 node_alice.example.com "Coordinate-location Format
			Desired"
	3.4.3 Warning code 703 Civic-location Format Desired Instead		3.4.3 Warning code 703 Civic-location Format Desired Instead
	A Warning header with the code 703 "Civic-location Format Desired"		A Warning header with the code 703 "Civic-location Format Desired"
	means the location format supplied in the request (probably		means the location format supplied in the request (probably
	formatted in geo), by-value or by-reference, was understood and		formatted in coordinate), by-value or by-reference, was understood
	supported, but that the recipient, or an application on the		and supported, but that the recipient, or an application on the
	recipient prefers, or can only process location in the		recipient prefers, or can only process location in the
	civic-location format.		civic-location format.
	A typical reaction to receiving this Warning code is to resend the		A typical reaction to receiving this warning code is to resend the
	original message with location formatted in civic instead.		original message with location formatted in civic instead.
	Recommended warn-text: Civic-location Format Desired		Recommended warn-text: Civic-location Format Desired
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 703 alice.example.com "Civic-location Format Desired"		Warning: 703 alice.example.com "Civic-location Format Desired"
	3.4.4 Warning code 704 Cannot Parse Location Supplied		3.4.4 Warning code 704 Cannot Parse Location Supplied
	A Warning header with the code 704 "Cannot parse location supplied"		A Warning header with the code 704 "Cannot parse location supplied"
	means the location provided, whether by-value or by-reference in a		means the location provided, whether by-value or by-reference, in a
	request is not well formed.		request is not well formed.
	Recommended warn-text: Cannot parse location supplied		Recommended warn-text: Cannot parse location supplied
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 704 alice.example.com "Cannot parse location supplied"		Warning: 704 alice.example.com "Cannot parse location supplied"
	3.4.5 Warning code 705 Cannot Find Location		3.4.5 Warning code 705 Cannot Find Location
	A Warning header with the code 705 "Cannot find location" means		A Warning header with the code 705 "Cannot find location" means
	location should have been in the message received, but the recipient		location should have been in the message received, but the recipient
	cannot find it, either because it is not in the message, or it is		cannot find it, either because it is not in the message, or it is
	encrypted/opaque to the recipient.		encrypted/opaque to the recipient.
	A typical reaction to receiving this error would be for the location		A typical reaction to receiving this warning code is for the
	sender to verify it has indeed included location in the new request		location sender to verify that it has indeed included location
	and send the message again.		information in the request and then to send the request again.
	Recommended warn-text: Cannot find location		Recommended warn-text: Cannot find location
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 705 alice.example.com "Cannot find location"		Warning: 705 alice.example.com "Cannot find location"
	3.4.6 Warning code 706 Conflicting Locations Supplied		3.4.6 Warning code 706 Conflicting Locations Supplied
	A Warning header with the code 706 "Conflicting Locations Supplied"		A Warning header with the code 706 "Conflicting Locations Supplied"
	means a location recipient received more than one location		means a location recipient received more than one location
	describing where the target is, and is either unsure which whole		describing where the target is, and is either unsure which whole
	location is true or which parts of multiple locations make up where		location is true or which parts of multiple locations make up where
	the target is. This is generally a case of either too much		the target is. This is generally a case of either too much
	information, and the information is conflicting.		information, and the information is conflicting.
	A typical reaction to receiving this error is to reduce the number		A typical reaction to receiving this warning code is to reduce the
	of different locations supplied in the request, and send another		number of different locations supplied in the request, and send
	message to the location recipient.		another message to the location recipient.
	Recommended warn-text: Conflicting Locations Supplied		Recommended warn-text: Conflicting Locations Supplied
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 706 alice.example.com "conflicting locations supplied"		Warning: 706 alice.example.com "conflicting locations supplied"
	3.4.7 Warning code 707 Incomplete Location Supplied		3.4.7 Warning code 707 Incomplete Location Supplied
	A Warning header with the code 707 "Incomplete Location Supplied"		A Warning header with the code 707 "Incomplete Location Supplied"
	means there is not enough location information, by-value or		means there is not enough location information, by-value or
	by-reference, to determine where the location target is.		by-reference, to determine where the location target is.
	A typical reaction to receiving this message is for the sender to		A typical reaction to receiving this warning code is for the
	Convey more information if it is willing to do so.		location sender to convey more location information, if doing so is
			allowed by local policy.
	Recommended warn-text: Incomplete location supplied		Recommended warn-text: Incomplete location supplied
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 707 alice.example.com "Incomplete location supplied"		Warning: 707 alice.example.com "Incomplete location supplied"
	3.4.8 Warning code 708 Cannot Dereference		3.4.8 Warning code 708 Cannot Dereference
	A Warning header with the code 708 "Cannot dereference" means the		A Warning header with the code 708 "Cannot dereference" means the
	skipping to change at page 12, line 6 ¶		skipping to change at page 12, line 17 ¶
	A Warning header with the code 720 "Unsupported Schema - sip		A Warning header with the code 720 "Unsupported Schema - sip
	desired" means the location dereferencer cannot dereference using		desired" means the location dereferencer cannot dereference using
	the location-by-reference URI schema supplied because it does not		the location-by-reference URI schema supplied because it does not
	support the necessary protocol to do this. This Warning code means		support the necessary protocol to do this. This Warning code means
	the location recipient can dereference the target's location using a		the location recipient can dereference the target's location using a
	sip-URI schema. There can be more than one Warning code in a		sip-URI schema. There can be more than one Warning code in a
	Warning header, indicated in this context the recipient can		Warning header, indicated in this context the recipient can
	dereference using each schema protocol included in the Warning		dereference using each schema protocol included in the Warning
	header.		header.
	A typical reaction to receiving this error would be for the location		A typical reaction to receiving this warning code would be for the
	sender to send a URI with the sip schema.		location sender to send a URI with the sip schema.
	Recommended warn-text: unsupported schema		Recommended warn-text: unsupported schema
	An example usage in a SIP 424 response:		An example usage in a SIP 424 response:
	Warning: 720 alice.example.com "unsupported schema - sip desired"		Warning: 720 alice.example.com "unsupported schema - sip desired"
	3.4.12 Warning code 721 Unsupported Schema - sips desired		3.4.12 Warning code 721 Unsupported Schema - sips desired
	A Warning header with the code 721 "Unsupported Schema - sips		A Warning header with the code 721 "Unsupported Schema - sips
	skipping to change at page 13, line 30 ¶		skipping to change at page 13, line 38 ¶
	infrastructure, and therefore would not understand which proxy will		infrastructure, and therefore would not understand which proxy will
	do the location-based routing function, if any.		do the location-based routing function, if any.
	3.6 Using sip/sips/pres as a Dereference Protocol		3.6 Using sip/sips/pres as a Dereference Protocol
	A sip, sips or pres URI SHOULD be included in a Geolocation header		A sip, sips or pres URI SHOULD be included in a Geolocation header
	for the location-by-reference URI. When pres: is used, if the		for the location-by-reference URI. When pres: is used, if the
	resulting resolution, per [RFC3851], resolves to a sip: or sips:		resulting resolution, per [RFC3851], resolves to a sip: or sips:
	URI, this section applies. Use of other protocols for dereferencing		URI, this section applies. Use of other protocols for dereferencing
	of a pres: URI is not defined, and such use is subject to review		of a pres: URI is not defined, and such use is subject to review
	against RFC3693 using protocol criteria.		against RFC 3693 using protocol criteria.
	Dereferencing using sip or sips MUST be accomplished by treating the		Dereferencing using sip or sips MUST be accomplished by treating the
	URI as a presence URI and dereferencing is accomplished by a		URI as a presence URI and dereferencing it by sending a SUBSCRIBE
	SUBSCRIBE to a presence service per [RFC3856]. The resulting NOTIFY		request to a presence server as per [RFC3856]. The resulting NOTIFY
	will contain a PIDF, which MUST contain a PIDF-LO.		will contain a PIDF, which MUST contain a PIDF-LO.
	When used in this manner, SIP is a using protocol per [RFC3693] and		When used in this manner, SIP is a using protocol per [RFC3693] and
	elements receiving location MUST honor the 'usage-element' rules as		elements receiving location MUST honor the 'usage-element' rules as
	defined in Section 3.4 above.		defined in Section 3.4 above.
	A dereference of a location-by-reference URI using SUBSCRIBE is not		A dereference of a location-by-reference URI using SUBSCRIBE is not
	violating a PIDF-LO 'retransmission-allowed' element value set to		violating a PIDF-LO 'retransmission-allowed' element value set to
	'no', as the NOTIFY is the only message in this multi-message series		'no', as the NOTIFY is the only message in this multi-message series
	of transactions that contains the UAC's location, with the location		of transactions that contains the UAC's location, with the location
	recipient being the only SIP element to receive location - which the		recipient being the only SIP element to receive location - which is
	purpose of this extension: to convey location to a specific		the purpose of this extension: to convey location to a specific
	destination.		destination.
	4. Examples		4. Examples
	Three examples of messages providing location are provided. One		Three examples of messages providing location are provided. One
	shows location-by-value with geo-coordinates, one shows		shows location-by-value with coordinates, one shows
	location-by-value with civic location and the third shows		location-by-value with civic location and the third shows
	location-by-reference. The examples for (Geo format) are taken		location-by-reference. The examples for (Coordinate format) are
	from [RFC3825] and (Civic format) are taken from [ID-CIVIC] and are		taken from [RFC3825] and (Civic format) are taken from [RFC4776]
	for the exact same position on the Earth. The differences between		and are for the exact same position on the Earth. The differences
	the two formats is within the <gp:location-info> of the examples.		between the two formats is within the <gp:location-info> of the
	Other than this portion of each PIDF-LO, the rest is the same for		examples. Other than this portion of each PIDF-LO, the rest is the
	both location formats.		same for both location formats.
	4.1 Location-by-value (Coordinate Format)		4.1 Location-by-value (Coordinate Format)
	This example shows an INVITE message with a coordinate, or geo		This example shows an INVITE message with a coordinate, or
	location. In this example, the SIP request uses a sips-URI		coordinate location. In this example, the SIP request uses a
	[RFC3261], meaning this message is TLS protected on a hop-by-hop		sips-URI [RFC3261], meaning this message is TLS protected on a
	basis all the way to Bob's domain.		hop-by-hop basis all the way to Bob's domain.
	INVITE sips:bob@biloxi.example.com SIP/2.0		INVITE sips:bob@biloxi.example.com SIP/2.0
	Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9		Via: SIP/2.0/TLS pc33.atlanta.example.com;branch=z9hG4bK74bf9
	Max-Forwards: 70		Max-Forwards: 70
	To: Bob <sips:bob@biloxi.example.com>		To: Bob <sips:bob@biloxi.example.com>
	From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl		From: Alice <sips:alice@atlanta.example.com>;tag=9fxced76sl
	Call-ID: 3848276298220188511@atlanta.example.com		Call-ID: 3848276298220188511@atlanta.example.com
	Geolocation: <cid:alice123@atlanta.example.com>		Geolocation: <cid:alice123@atlanta.example.com>
	;inserted-by=endpoint		;inserted-by=endpoint
	Supported: geolocation		Supported: geolocation
	skipping to change at page 18, line 22 ¶		skipping to change at page 18, line 32 ¶
	A PIDF includes identity information. It is possible for the		A PIDF includes identity information. It is possible for the
	identity in the PIDF to be anonymous. Implementations of this		identity in the PIDF to be anonymous. Implementations of this
	extension should consider the appropriateness of including an		extension should consider the appropriateness of including an
	anonymous identity in the location information where a real identity		anonymous identity in the location information where a real identity
	is not required. When using location-by-reference, it is		is not required. When using location-by-reference, it is
	RECOMMENDED that the URI not contain any identifying information		RECOMMENDED that the URI not contain any identifying information
	(for example use 3fg5t5yqw@example.com rather than		(for example use 3fg5t5yqw@example.com rather than
	alice@example.com)		alice@example.com)
	The entities receiving location MUST obey the privacy		The entities receiving location MUST obey the privacy
	and security rules in the PIDF-LO as described in RFC4119, regarding		and security rules in the PIDF-LO as described in RFC 4119,
	retransmission and retention.		regarding retransmission and retention.
	Self-signed certificates SHOULD NOT be used for protecting PIDF,		Self-signed certificates SHOULD NOT be used for protecting a PIDF,
	as the sender does not have a secure identity of the recipient.		as the sender does not have a secure identity of the recipient.
	More than one location representation or format, for example: civic		More than one location representation or format, for example: civic
	and geo, MAY be included in the same message body part, but all MUST		and coordinate, MAY be included in the same message body part, but
	point at the same position on the earth. Multiple representations		all MUST point at the same position on the earth. Multiple
	allow the recipient to use the most convenient representation of		representations allow the recipient to use the most convenient
	location.		representation of location.
	There MAY be more than one PIDF-LO in the same SIP message, but each		There MAY be more than one PIDF-LO in the same SIP message, so long
	in separate message body parts. Each location body part MAY point at		as each is in a separate message body part. Each location body part
	different positions on the earth. The meaning of such a		MAY point at different positions on the earth. The meaning of such
	construction is not defined, and may cause confusion at the		a construction is not defined, and may cause confusion at the
	recipient		recipient.
	5.1 UAC Behavior		5.1 UAC Behavior
	A UAC may send location because it was requested to, to facilitate		A UAC may send location because it was requested to, to facilitate
	location-based routing, or spontaneously (i.e. a purpose not defined		location-based routing, or spontaneously (i.e. a purpose not defined
	in this document but known to the UAC). A UAC MAY receive location		in this document but known to the UAC). A UAC MAY receive location
	from the UAS spontaneously.		from the UAS spontaneously.
	A UAC conveying location MUST include a Geolocation header with		A UAC conveying location MUST include a Geolocation header with
	either a location by-value indication (a cid-URL), or a location		either a location by-value indication (a cid-URL), or a location
	by-reference indication (a dereferenceable URI). A location body		by-reference indication (a dereferenceable URI). A location body
	sent without a Geolocation header MUST NOT occur. The UAC		sent without a Geolocation header MUST NOT occur. The UAC
	supporting this extension MUST include a Supported header with the		supporting this extension MUST include a Supported header with the
	geolocation option tag.		geolocation option tag.
	The presence of the geolocation option tag in a Supported header		The presence of the geolocation option tag in a Supported header
	without a Geolocation header in the same message informs a receiving		without a Geolocation header in the same message informs a receiving
	SIP element the UAC understands the concept of location, but it does		SIP element the UAC understands the concept of location, but it does
	not know its location at this time. Certain scenarios exist		not know or wish to convey its location at this time. Certain
	(location-based routing) in which location is required in a message		scenarios exist (location-based routing) in which location is
	in order to route the message properly. This affects how a UAS or		required in a message in order to route the message properly. This
	SIP server reacts to such a message.		affects how a UAS or SIP server reacts to such a message.
	The geolocation option tag SHOULD NOT be used in the Proxy-Require		The geolocation option tag SHOULD NOT be used in the Proxy-Require
	Header.		Header.
	If the UAC inserts a geolocation header, it SHOULD include a		If the UAC inserts a geolocation header, it SHOULD include a
	"inserted-by=endpoint" parameter. For example:		"inserted-by=endpoint" parameter. For example:
	Geolocation: <cid:alice123@atlanta.example.com>;		Geolocation: <cid:alice123@atlanta.example.com>;
	inserted-by=endpoint		inserted-by=endpoint
	UACs receiving a 424 (Bad Location Information) response MAY find a		UACs receiving a 424 (Bad Location Information) response MAY find a
	more granular cause for the location based error in a Warning		more granular cause for the location based error in a Warning
	header. Section 3.4 extends the list of IANA registered Warning		header. Upon receiving a 424 error response, the UAC SHOULD take
	codes, specifically for location errors within the request. The		appropriate steps based on the warning code before attempting to
	UAC SHOULD learn from the Warning code in the response and take
	appropriate steps based on that error given before attempting to
	convey location again. See Section 3.4. for the list of new		convey location again. See Section 3.4. for the list of new
	location specific Warning codes.		location specific Warning codes, all of which are IANA registered in
			this document.
	There MAY be future work defining additional error information, say		There MAY be future work defining additional error information, say
	in an XML body, indicating exactly what the error was, if any of the		in an XML body, indicating exactly what the error was, if any of the
	new Warning codes are ambiguous.		new Warning codes are ambiguous.
	The behavior of the UAC receiving location is the same as the UAS,		The behavior of the UAC receiving location is the same as the UAS,
	as below, except a UAC cannot send a Warning code indicating		as below, except a UAC cannot send a Warning code indicating
	something was wrong with the location supplied by the UAS. In this		something was wrong with the location supplied by the UAS. In this
	case, the location information SHOULD just be ignored in this		case, the location information SHOULD just be ignored in this
	transaction. A subscription is a better means of getting a UAS's		transaction. A UAC subscribing to a UAS for its location is a
	location.		better means of acquiring the UAS's location. This is a seeking or
			pull model scenario, which is not defined here, and left for future
			study.
	5.2 UAS Behavior		5.2 UAS Behavior
	If the Geolocation header is present, the URI contained in as a		If the Geolocation header is present, the type of URI contained in
	header field will indicate if location has been conveyed by-value in		the header field will indicate if location has been conveyed
	a message body (part) or by-reference, requiring an additional		by-value in a message body (part) or by-reference, requiring an
	dereference transaction. If the by-reference URI is sip:, sips: or		additional dereference transaction. If the by-reference URI is
	pres:, the UAS will initiate a SUBSCRIBE to the URI provided to		sip:, sips: or pres:, the UAS will initiate a SUBSCRIBE to the URI
	retrieve the PIDF-LO of the UAC per [RFC3856]. If successful, the		provided to retrieve the PIDF-LO of the UAC per [RFC3856]. If
	PIDF-LO of the UAC will be returned in the NOTIFY request from the		successful, the PIDF-LO of the UAC will be returned in the NOTIFY
	server.		request from the server.
	A Require header with the geolocation option tag indicates the		A Require header with the geolocation option tag indicates the
	UAC is requiring the UAS understand this extension or error the		UAC is requiring the UAS understand this extension or else send an
	message. A 420 (Bad Extension) with a geolocation option tag in a		error response. A 420 (Bad Extension) with a geolocation option tag
	Unsupported header would be the appropriate response.		in a Unsupported header would be the appropriate response.
	If the UAC conveys location in a request, but the UAS has one or		If the UAC conveys location in a request, but the UAS has one or
	more problems with the location in the request (or while attempting		more problems with the location in the request (or while attempting
	to dereference the UAC's location), a 424 (Bad Location Information)		to dereference the UAC's location), a 424 (Bad Location Information)
	response would be an appropriate response. If the UAS can indicate		response would be an appropriate response. If the UAS can indicate
	what the problem is with the location in the request, in the form of		what the problem is with the location in the request, in the form of
	one of the new Warning codes specifically about location errors, the		one of the new Warning codes specifically about location errors, the
	Warning header SHOULD be included along with the most applicable		Warning header SHOULD be included along with the most applicable
	Warning code(s). Zero or more Warning codes are allowed in a		Warning code(s). Zero or more Warning codes are allowed in a
	response.		response.
	skipping to change at page 20, line 37 ¶		skipping to change at page 20, line 48 ¶
	5.3 Proxy Behavior		5.3 Proxy Behavior
	[RFC3261] states message bodies cannot be added by proxies.		[RFC3261] states message bodies cannot be added by proxies.
	However, a proxy may add a header to a message. This implies that a		However, a proxy may add a header to a message. This implies that a
	proxy MAY add a geolocation header with location-by-reference, but		proxy MAY add a geolocation header with location-by-reference, but
	not location-by-value.		not location-by-value.
	A proxy MAY read the Geolocation header, and the associated body, if		A proxy MAY read the Geolocation header, and the associated body, if
	not S/MIME protected, in transit if present, and MAY use the		not S/MIME protected, in transit if present, and MAY use the
	contents of the header to make location-based routing decisions.		contents of the header to make location-based routing decisions.
	More than one Geolocation header or header value in a message is		More than one Geolocation header or header value in a message is
	permitted. The meaning of such a construction is not defined, and		permitted. The meaning of such a construction is not defined, and
	may cause confusion at the recipient.		may cause confusion at the recipient.
	Proxies receiving location where the proxy performs location-based		Proxies that perform location-based routing may need to consult
	routing may need to consult external databases or systems to		external databases or systems to determine the route. Transmission
	determine the route. Transmission of the location information		of the location information (which SHOULD NOT reveal identity, even
	(which SHOULD NOT reveal identity, even if the proxy knows the		if the proxy knows the identity) is governed by the
	identity) is governed by the 'retransmission-allowed' and		'retransmission-allowed' and 'routing-query-allowed':
	'routing-query-allowed':
	Retransmission-allowed Routing-query-allowed Transmission for Query		Retransmission-allowed Routing-query-allowed Transmission for Query
	---------------------- --------------------- ----------------------		---------------------- --------------------- ----------------------
	"no" or not present "no" or not present Not Allowed		"no" or not present "no" or not present Not Allowed
	"no" or not present "yes" Allowed		"no" or not present "yes" Allowed
	"yes" not present Allowed		"yes" not present Allowed
	"yes" "no" Not Allowed		"yes" "no" Not Allowed
	"yes" "yes" Allowed		"yes" "yes" Allowed
	If transmission is not allowed per the above, the proxy SHOULD		If transmission is not allowed per the above, the proxy SHOULD
	provide a suitable error response. The 424 (Bad Location) is the		provide a suitable error response. The 424 (Bad Location) is the
	appropriate response here.		appropriate response here.
	5.3.1 Proxy Behavior with Geolocation Header Parameters		5.3.1 Proxy Behavior with Geolocation Header Parameters
	When a message traverses a SIP intermediary, any existing header		When a message traverses a SIP intermediary, any existing
	value URI and header parameter MUST NOT be modified or deleted,		Geolocation header value (URI or header parameter) MUST NOT be
	but MAY be augmented to indicate if the message was routed based on		deleted. A Geolocation header value (URI or header parameter) MAY
	a specific geolocation URI. For example:		only be modified to indicate if the message was routed based on a
			specific geolocation URI. Further modification of this Geolocation
			header MUST NOT occur. For example:
	Geolocation: <cid:alice123@atlanta.example.com>;		Geolocation: <cid:alice123@atlanta.example.com>;
	inserted-by=endpoint; message-routed-on-this-uri		inserted-by=endpoint; message-routed-on-this-uri
	A SIP intermediary MAY add a new Geolocation URI value to a message.		A SIP intermediary MAY add a new Geolocation URI value to a message.
	The proxy SHOULD NOT insert a location unless it is reasonably		The proxy SHOULD NOT insert a location unless it is reasonably
	certain it knows the actual location of the endpoint, for example,		certain it knows the actual location of the endpoint, for example,
	if it thoroughly understands the topology of the underlying access		if it thoroughly understands the topology of the underlying access
	network and it can identify the device reliably (in the presence of,		network and it can identify the device reliably (in the presence of,
	for example, NAT).		for example, NAT).
	skipping to change at page 23, line 48 ¶		skipping to change at page 24, line 9 ¶
	Quoting requirement #6 of [RFC3693]:		Quoting requirement #6 of [RFC3693]:
	"(Single Message Transfer) In particular, for tracking of		"(Single Message Transfer) In particular, for tracking of
	small target devices, the design should allow a single		small target devices, the design should allow a single
	message/packet transmission of location as a complete		message/packet transmission of location as a complete
	transaction."		transaction."
	When used for tracking, a simple NOTIFY or UPDATE normally is		When used for tracking, a simple NOTIFY or UPDATE normally is
	relatively small, although the PIDF itself can get large. Normal		relatively small, although the PIDF itself can get large. Normal
	RFC3261 procedures of reverting to TCP when the MTU size is exceeded		RFC 3261 procedures of reverting to TCP when the MTU size is
	would be invoked.		exceeded would be invoked.
	8. Security Considerations		8. Security Considerations
	Conveyance of physical location of a UAC raises privacy concerns,		Conveyance of physical location of a UAC raises privacy concerns,
	and depending on use, there may be authentication and integrity		and depending on use, there may be authentication and integrity
	concerns. This document calls for conveyance to normally be		concerns. This document calls for conveyance to normally be
	accomplished through secure mechanisms (like S/MIME or TLS). In		accomplished through secure mechanisms (like S/MIME or TLS). In
	cases where a session set-up is routed based on the location of the		cases where a session set-up is routed based on the location of the
	UAC initiating the session or SIP MESSAGE, securing the by-value		UAC initiating the session or SIP MESSAGE, securing the by-value
	location with an end-to-end mechanism such as S/MIME is problematic,		location with an end-to-end mechanism such as S/MIME is problematic,
	skipping to change at page 25, line 7 ¶		skipping to change at page 25, line 19 ¶
	Default reason phrase: Bad Location Information		Default reason phrase: Bad Location Information
	This SIP Response code is defined in section 3.3 of this document.		This SIP Response code is defined in section 3.3 of this document.
	9.4 IANA Registration of New Warning Codes for Location		9.4 IANA Registration of New Warning Codes for Location
	New location specific Warning codes are created by this document,		New location specific Warning codes are created by this document,
	with the definitions in Section 3.4 of this document.		with the definitions in Section 3.4 of this document.
	701 Location Format Not Supported		701 Location Format Not Supported
	702 Geo-location Format Desired Instead		702 Coordinate-location Format Desired Instead
	703 Civic-location Format Desired Instead		703 Civic-location Format Desired Instead
	704 Cannot Parse Location Supplied		704 Cannot Parse Location Supplied
	705 Cannot Find Location		705 Cannot Find Location
	706 Conflicting Locations Supplied		706 Conflicting Locations Supplied
	707 Incomplete Location Supplied		707 Incomplete Location Supplied
	708 Cannot Dereference		708 Cannot Dereference
	709 Dereference Denied		709 Dereference Denied
	710 Dereference Timeout		710 Dereference Timeout
	711 Cannot Process Dereference		711 Cannot Process Dereference
	720 Unsupported Schema - sip desired		720 Unsupported Schema - sip desired
	skipping to change at page 25, line 31 ¶		skipping to change at page 25, line 43 ¶
	Adding new location specific Warning codes, or modifying to existing		Adding new location specific Warning codes, or modifying to existing
	location specific Warning codes requires an RFC and community		location specific Warning codes requires an RFC and community
	review.		review.
	10. Acknowledgements		10. Acknowledgements
	To Dave Oran for helping to shape this idea. To Jon Peterson and		To Dave Oran for helping to shape this idea. To Jon Peterson and
	Dean Willis on guidance of the effort. To Allison Mankin, Dick		Dean Willis on guidance of the effort. To Allison Mankin, Dick
	Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom,		Knight, Hannes Tschofenig, Henning Schulzrinne, James Winterbottom,
	Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith		Jeroen van Bemmel, Jean-Francois Mule, Jonathan Rosenberg, Keith
	Drage, Marc Linsner, Martin Thomson, Mike Hammer and Paul Kyzivat		Drage, Marc Linsner, Martin Thomson, Mike Hammer, Paul Kyzivat,
	for constructive feedback. Thanks to Dan Wing for help with the		Shida Shubert, and Matt Lepinski for constructive feedback. A
	S/MIME example.		special thanks to Dan Wing for help with the S/MIME example.
	11. References		11. References
	11.1 References - Normative		11.1 References - Normative
	[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.		[RFC3261] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
	Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:		Peterson, R. Sparks, M. Handley, and E. Schooler, "SIP:
	Session Initiation Protocol", RFC 3261, May 2002.		Session Initiation Protocol", RFC 3261, May 2002.
	[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
	"Geopriv Requirements", RFC 3693, February 2004
	[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object		[RFC4119] J. Peterson, "A Presence-based GEOPRIV Location Object
	Format", RFC 4119, December 2005		Format", RFC 4119, December 2005
	[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate		[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
	Requirement Levels", RFC 2119, March 1997		Requirement Levels", RFC 2119, March 1997
	[RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource		[RFC2392] E. Levinson, " Content-ID and Message-ID Uniform Resource
	Locators", RFC 2393, August 1998		Locators", RFC 2393, August 1998
	[RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J.		[RFC3863] H. Sugano, S. Fujimoto, G. Klyne, A. Bateman, W. Carr, J.
	skipping to change at page 26, line 25 ¶		skipping to change at page 26, line 34 ¶
	[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,		[RFC3428] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema,
	D. Gurle, "Session Initiation Protocol (SIP) Extension for		D. Gurle, "Session Initiation Protocol (SIP) Extension for
	Instant Messaging" , RFC 3428, December 2002		Instant Messaging" , RFC 3428, December 2002
	[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE		[RFC3311] J. Rosenberg, "The Session Initiation Protocol (SIP) UPDATE
	Method", RFC 3311, October 2002		Method", RFC 3311, October 2002
	[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific		[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
	Event Notification", RFC 3265, June 2002.		Event Notification", RFC 3265, June 2002.
			[RFC3851] B. Ramsdell, "Secure/Multipurpose Internet Mail Extensions
			(S/MIME) Version 3.1 Message Specification", RFC 3851, July
			2004
	11.2 References - Informative		11.2 References - Informative
	[ID-ERROR] J. Polk, "A Geopriv Registry for Location-based Error		[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
	Response Codes",		"Geopriv Requirements", RFC 3693, February 2004
	draft-polk-geopriv-location-based-error-registry-00, "work
	in progress", October 2006
	[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host		[RFC3825] J. Polk, J. Schnizlein, M. Linsner, "Dynamic Host
	Configuration Protocol Option for Coordinate-based Location		Configuration Protocol Option for Coordinate-based Location
	Configuration Information", RFC 3825, July 2004		Configuration Information", RFC 3825, July 2004
	[ID-CIVIC] H. Schulzrinne, " Dynamic Host Configuration Protocol		[RFC4776] H. Schulzrinne, " Dynamic Host Configuration Protocol
	(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration		(DHCPv4 and DHCPv6) Option for Civic Addresses Configuration
	Information ", draft-ietf-geopriv-dhcp-civil-09, "work in		Information ", draft-ietf-geopriv-dhcp-civil-09, "work in
	progress", January 2006		progress", January 2006
	Author Information		Author Information
	James Polk		James Polk
	Cisco Systems		Cisco Systems
	3913 Treemont Circle 33.00111N		3913 Treemont Circle 33.00111N
	Colleyville, Texas 76034 96.68142W		Colleyville, Texas 76034 96.68142W
	skipping to change at page 27, line 50 ¶		skipping to change at page 28, line 11 ¶
	Motivation: in case a UAC has moved prior to the establishment of a		Motivation: in case a UAC has moved prior to the establishment of a
	dialog between UAs, the UAC must be able to send new location		dialog between UAs, the UAC must be able to send new location
	information. In the case of location having been conveyed,		information. In the case of location having been conveyed,
	and the UA moves, it needs a means to update the conveyed to		and the UA moves, it needs a means to update the conveyed to
	party of this location change.		party of this location change.
	UAC-7 The privacy and security rules established within [RFC3693]		UAC-7 The privacy and security rules established within [RFC3693]
	that would categorize SIP as a 'using protocol' must be met.		that would categorize SIP as a 'using protocol' must be met.
	UAC-8 The PIDF-LO [RFC4119] is a mandatory to implement format for		UAC-8 The PIDF-LO [RFC 4119] is a mandatory to implement format for
	location conveyance within SIP, whether included by-value or		location conveyance within SIP, whether included by-value or
	by-reference.		by-reference.
	Motivation: interoperability with other IETF location protocols and		Motivation: interoperability with other IETF location protocols and
	mechanisms		mechanisms
	UAC-9 There must be a mechanism for the UAC to request the UAS send		UAC-9 There must be a mechanism for the UAC to request the UAS send
	its location		its location
	UAC-10 There must be a mechanism to differentiate the ability of the		UAC-10 There must be a mechanism to differentiate the ability of the
	skipping to change at page 29, line 17 ¶		skipping to change at page 29, line 30 ¶
	Proxy-2 There must be a unique 4XX response informing the UAC it		Proxy-2 There must be a unique 4XX response informing the UAC it
	did not provide applicable location information.		did not provide applicable location information.
	Appendix B. Changes from Prior Versions		Appendix B. Changes from Prior Versions
	[NOTE TO RFC-EDITOR: If this document is to be published as an RFC,		[NOTE TO RFC-EDITOR: If this document is to be published as an RFC,
	this Appendix B is to be removed prior to that event.]		this Appendix B is to be removed prior to that event.]
	This is a list of the changes that have been made from the SIP WG		This is a list of the changes that have been made from the SIP WG
			version -06 to this version -07:
			- Fixed nits from Tools page
			- fixed subtle ambiguity in some sentences and misc. errors, based
			on feedback from -06.
			This is a list of the changes that have been made from the SIP WG
	version -05 to this version -06:		version -05 to this version -06:
	- cleaned up some inconsistencies wrt the S/MIME example in Section		- cleaned up some inconsistencies wrt the S/MIME example in Section
	4.2		4.2
	- changed the ABNF to include the ability to indicate which SIP		- changed the ABNF to include the ability to indicate which SIP
	element inserted a particular location URI, and how a message		element inserted a particular location URI, and how a message
	routing server indicates which location the message was routed		routing server indicates which location the message was routed
	upon (based on the location in the message)		upon (based on the location in the message)
	- changed the granular error code from a Reason header indication to		- changed the granular error code from a Reason header indication to
	a Warning code indication (section 3.4), and IANA registered 14		a Warning code indication (section 3.4), and IANA registered 14
	new Warning codes in this document		new Warning codes in this document
	- As a consequence of the above bullet, changed the specific SIP		- As a consequence of the above bullet, changed the specific SIP
	element behaviors of each SIP element regarding sending or		element behaviors of each SIP element regarding sending or
	receiving a 424 response with a Warning header		receiving a 424 response with a Warning header
	- Added rules about indicating which SIP element inserted a		- Added rules about indicating which SIP element inserted a
	particular location into a message (a new Geolocation header		particular location into a message (a new Geolocation header
	parameter), as well as when a server adds another new header		parameter), as well as when a server adds another new header
	parameter indicating the request was routed based on a particular		parameter indicating the request was routed based on a particular
	location included in the message		location included in the message
	This is a list of the changes that have been made from the SIP WG		This is a list of the changes that have been made from the SIP WG
	version -04 to this version -05:		version -04 to this version -05:
	- altered the meaning of use of OPTIONS to not be for retrieving the		- altered the meaning of use of OPTIONS to not be for retrieving the
	location of a UAS, but for cases in which location is a required		location of a UAS, but for cases in which location is a required
End of changes. 60 change blocks.
	133 lines changed or deleted		153 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/