< draft-polk-sipping-location-requirements-00.txt		draft-polk-sipping-location-requirements-01.txt >
	Internet Engineering Task Force James M. Polk		Internet Engineering Task Force James M. Polk
	Internet Draft Cisco Systems		Internet Draft Cisco Systems
	Expiration: Dec 23rd, 2003		Expiration: April 27th, 2003 Brian Rosen
	File: draft-polk-sipping-location-requirements-00.txt		File: draft-polk-sipping-location-requirements-01.txt Marconi
	Session Initiation Protocol Location Requirements		Session Initiation Protocol Location Conveyance
	June 23rd, 2003		October 27th, 2003
	Status of this Memo		Status of this Memo
	This document is an Internet-Draft and is in full conformance		This document is an Internet-Draft and is in full conformance
	with all provisions of Section 10 of RFC2026.		with all provisions of Section 10 of RFC2026.
	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
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	skipping to change at page 1, line 36 ¶		skipping to change at page 1, line 36 ¶
	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		The list of Internet-Draft Shadow Directories can be accessed
	at http://www.ietf.org/shadow.html.		at http://www.ietf.org/shadow.html.
	Abstract		Abstract
	This document presents the requirements for an extension to the		This document presents the framework and requirements for an
	Session Initiation Protocol (SIP) [1] for conveyance of user		extension to the Session Initiation Protocol (SIP) [1] for
	location information from one Session Initiation Protocol (SIP)		conveyance of user location information from a Session Initiation
	User Agent to another SIP User Agent. The idea that in some cases		Protocol (SIP) user agent to another SIP entity. We consider cases
	the UAC's location could affect proper routing of the SIP message		where location information is conveyed from end to end, as well as
	is explored as well.		cases where message routing by intermediaries is influenced by the
			location of the session initiator.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
	1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3		1.1 Conventions . . . . . . . . . . . . . . . . . . . . . . . 3
			1.2 Changes from -00 . . . . . . . . . . . . . . . . . . . . 3
	2. In the Body or in a Header . . . . . . . . . . . . . . . . . 3		2. In the Body or in a Header . . . . . . . . . . . . . . . . . 3
	3. Scope of Location in a Message Body . . . . . . . . . . . . . 4		3. Scope of Location in a Message Body . . . . . . . . . . . . . 4
	4. Scope of Location in a Message Header . . . . . . . . . . . . 4		4. Requirements for UA-to-UA Location Conveyance . . . . . . . . 4
	4.1 Location in a Single Header . . . . . . . . . . . . . . . 4		5. Requirements for UA-to-Proxy Server Location Conveyance . . . 5
	4.2 Location in Separate Message Headers . . . . . . . . . . 5		6. Additional Requirements for Emergency Calls . . . . . . . . . 5
	5. Requirements for UA-to-UA Location Conveyance . . . . . . . . 5		7. Current Known Open issues . . . . . . . . . . . . . . . . . . 6
	6. Requirements for Proxy-Routed Location Conveyance . . . . . . 6		8. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 7		9. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7
	8. IANA Considerations . . . . . . . . . . . . . . . . . . . . 7		10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
	9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8		11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8		12. Author Information . . . . . . . . . . . . . . . . . . . . . 8
	11. Author Information . . . . . . . . . . . . . . . . . . . . . 8
	12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 8
	1. Introduction		1. Introduction
	This document presents the requirements for an extension to the		This document presents the framework and requirements for an
	Session Initiation Protocol (SIP) [1] for conveyance of user		extension to the Session Initiation Protocol (SIP) [1] for
	location information from one Session Initiation Protocol (SIP)		conveyance of user location information object described by [7] from
	User Agent to another SIP User Agent.		a SIP User Agent to another SIP entity.
	While reasonable people will initially lean strongly towards
	having any location conveyance in the message body only (where
	location confidentiality can be maintained), this document
	examines usage cases where intermediaries must act on the
	location information in order to determine where the session gets
	routed. One such example of this is US e911-type emergency
	sessions (voice or instant messaging). With this in mind, both
	instances will be looked at here to determine if the requirements
	are in fact different enough to necessitate two or more
	solutions.
	To be clear, the two cases that need to be looked at are the		There are several situations in which it is appropriate for SIP to
	following:		be used to convey Location Information (LI) from one SIP entity to
			another. This document specifies requirements when a SIP UAC knows
			its location by some means not specified herein, and needs to inform
			another SIP entity. One example is to reach your nearest pizza
			parlor. A chain of pizza parlors may have a single well known uri
			(sip:pizzaparlor.com), that is forwarded to the closest franchise by
			the pizzaparlor.com proxy server. The receiving franchise UAS uses
			the location information of the UAC to schedule your delivery.
	1. one involving a user of a User Agent wanting to transmit		Another important example is emergency calling. A call to
	his/her location to another user of a user agent for		sip:sos@example.com is an emergency call as in [3]. The example.com
	whatever reason (I want to tell you where I am); and		proxy server must route the call to the correct emergency response
			center (ERC) determined by the location of the caller. At the ERC,
			the UAS must determine the correct police/fire/ambulance/...
			service, which is also based on your location. In many
			jurisdictions, accurate location information is a required component
			of a call to an emergency center.
	2. a second case involving the UAC including its location in		A third example is a direction service, which might give you verbal
	order to allow an appropriate Emergency Response Center		directions to a venue from your present position. This is a case
	(ERC) to be contacted, such as a US e911 Public Safety		where only the destination UAS needs to receive the location
	Answering Point (because that User Agent has signaled for		information.
	help);
	This document does not discuss how the UAC discovers or is		This document does not discuss how the UAC discovers or is
	configured with its Location (either coordinate based or civil		configured with its location (either coordinate based or civil
	based). That work is being accomplished in the Geopriv Working		based). It also does not discuss the contents of the Location
	Group.		Object (LO). It does specify the requirements for the "using
			protocol" in [7].
	1.1 Conventions used in this document		1.1 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 [2].		in [2].
			1.2 Changes from -00 Version
			This is a list of the changes that have been made from the -00
			version of this ID:
			- Brian Rosen was brought on as a co-author
			- Requirements that a location header were negatively received in
			the previous version of this document. AD and chair advice was to
			move all location information into a message body (and stay away
			from headers)
			- Added a section of "emergency call" specific requirements
			- Added an Open Issues section to mention what hasn't been resolved
			yet in this effort
	2. In the Body or in a Header		2. In the Body or in a Header
	When one user agent wants to inform another user agent where they		When one user agent wants to inform another user agent where they
	are, it seems reasonable to have this accomplished by placing the		are, it seems reasonable to have this accomplished by placing the
	location information (coordinate or civil) in an S/Mime registered		location information (coordinate or civil) in an S/Mime registered
	and encoded message body, and sending it as part of a SIP request or		and encoded message body, and sending it as part of a SIP request or
	response. No routing of the request based on the location		response. No routing of the request based on the location
	information is required in this case; therefore no SIP Proxies		information is required in this case; therefore no SIP Proxies
	between these two UAs need to view the location information		between these two UAs need to view the location information
	contained in the SIP messages.		contained in the SIP messages.
	However, it may be infeasible to place the location information in		Although SIP [1} does not permit a proxy server to modify or delete
	the message body of requests where/when message routing is of		a body, there is no restriction on viewing bodies. However, S/MIME
	particular importance for proper session establishment with the		protection implemented on bodies is only specified between UAS and
	intended party or parties (i.e. calling an ERC).		UAC and if engaged, would render the location object opaque to a
			proxy server. This problem is similar to that raised in Session
			Policy [8], where an intermediary may need information in a body,
			such as IP address of media streams or codec choices to route a call
			properly. Requirements in [8] are applicable to routing based on
			location, and are incorporated in these requirements by reference.
	SIP message bodies are not viewed by Proxy Servers [per 1] in order		It is conceivable to create a new header for location information.
	to do proper call routing. The current proposal in front of the		However, [7] prefers S/MIME for security of Location Information,
	SIPPING WG is to use the mechanism described in [3] to universally		and indeed S/MIME is preferable in SIP for protecting one part of a
	signal for help. This "sos@example.com" URI is proposed to describe		message. Accordingly, these requirements specify location be
	many, if not all ERCs in a region or country - regardless of the		carried in a body.
	original home domain that UA is from. This poses a particular
	problem when a User Agent is signaling via a Proxy that is not
	within the civil boundaries of the appropriate PSAP for that user.
	For example, a large enterprise has a campus that spans more than
	one PSAP jurisdiction, a UA initiates a session containing the To
	header "sos@example.com". Where will that Proxy route the SIP
	Request to? The problem is compounded if a managed domain only has
	Proxies in one location of a multi site infrastructure - including
	the possibility of traversing state or country boundaries in cases
	in which the UA is mobile.
	Routing a session set-up or instant message, such as SIP MESSAGE		It is the use of S/MIME however, that limits routing based on
	from [4], becomes an Achilles Heel for SIP if the user agent is		location. Therefore, it seems appropriate to require that, where
	unaware of the correct ERC routing and expects the correct ERC to be		routing is dependent on location, protection of the location
	selected by the SIP proxy routing machinery..		information object be accomplished by other mechanisms, probably TLS
			("sips:" from [1]). It is envisioned that S/MIME SHOULD be used
			when location information is not required by proxy servers, and TLS
			SHOULD be used when it is.
	This document does not address the behavior or configuration of SIP		This document does not address the behavior or configuration of SIP
	Proxy Servers in these cases in order to accomplish location-		Proxy Servers in these cases in order to accomplish location-
	sensitive routing. That is out of scope, and left for further		sensitive routing. That is out of scope, and left for further
	(complementary) efforts.		(complementary) efforts.
	3. Scope of Location in a Message Body		3. Scope of Location in a Message Body
	If the location information is to be contained within a message		If the location information is to be contained within a message
	body, the rules stated in section 7 of [1] regarding multipart MIME		body, and either another body (SDP for example) is also to be sent
	bodies MUST be followed. The format and privacy/security rules of		in the message, or the LO is to be protected with S/MIME, the rules
	the location information SHOULD be defined within the Geopriv WG.		stated in section 7 of [1] regarding multipart MIME bodies MUST be
			followed. The format and privacy/security rules of the location
	4. Scope of Location in a Message Header		information SHOULD be defined within the Geopriv WG.
	If the location information of the UAC is to be contained within the
	SIP message header (verses a message body as stated above), one
	design issue is whether location field(s) are contained within a
	single header, or multiple headers. The following 2 subsections
	cover both of these choices for discussion.
	4.1 Location in a Single Header
	Placing location information within a single header of a SIP message
	has some big advantages:
	- it is easier to specify the semantics when there are missing
	fields
	- it makes readability much easier when reviewing all the location
	fields contained within the SIP message header ordered as if in a
	list
	- an order of the location fields can be specified within this
	single header (ex: Datum, then Latitude, then Longitude, then
	Altitude, then... or country, then state/province, then
	county/region, then city, then district/borough...)
	This might be important if section 7.3.1 of [1] is still true
	expedited parsing in Proxies and at the destination.
	There exist two documents on Location Configuration Information
	within the Geopriv Working Group, one for Coordinate based location
	representation (Lat, Long, Alt, Datum, etc) in [5] and one for Civil
	based Location representation (country, State/province, city, etc)
	in [6]. Each of these documents should be looked to as a basis for
	consistency in fields present as well as scope of the fields.
	If a field is missing, it probably was left out intentionally by the
	UAC (either because that device didn't know what to populate a
	particular field with, or a policy prevented it from being included
	within that SIP message).
	Any location privacy policy of a user agent within a particular
	domain should allow the most precise location available be presented
	as an S/MIME body in the SIP Request or response message once a
	verifiable ERC is determined to be the intended destination of that
	session.
	4.2 Location in Separate Message Headers
	Creating separate SIP headers for each location field type
	(latitude, longitude, country, city, etc) does make each header
	clean and concise. A grouping of these location headers should occur
	for readability when viewing the location headers within a SIP
	message header. And since expediting the processing of emergency
	calls is important, the header placement considerations of section
	7.3.1 of [1] apply to these headers when making emergency calls
	Each of the message headers should be unique in name within a
	location conveyance type.
	In providing location information, the UAC should provide as much		4. Requirements for UA-to-UA Location Conveyance
	information as possible within a certain type of location field
	group (coordinate or civil), and not mix between groups. In other
	words, a Latitude header should be used if a coordinate location is
	being provided by the UAC, but is not by itself realistically
	valuable information if a complete set civil location headers is
	also present.
	There exist two documents on Location Configuration Information		The following are the requirements for UA-to-UA Location Conveyance
	within the Geopriv Working Group, one for Coordinate based location		situations:
	representation (Lat, Long, Alt, Datum, etc) in [5] and one for Civil
	based Location representation (country, State/province, city, etc)
	in [6]. Each of these documents should be looked to as a basis for
	consistency in fields present as well as scope of the fields.
	If a desire of the SIP working group is to limit the number of		U-U1 - MUST work with dialog-initiating SIP Requests and responses,
	headers that require IANA registration (and coding for), then		as well as the SIP MESSAGE method[4], and SHOULD work with
	fulfilling this requirements document will add as little as 2 to		most SIP messages.
	that process (1 for coordinate location and 1 for civil location),
	or as many as 30+ if each location field requires a unique header.
	5. Requirements for UA-to-UA Location Conveyance		U-U2 - UAC Location information SHOULD remain confidential in route
			to the destination UA
	The following are the requirements for UA-to-UA Location Conveyance		U-U3 - The privacy and security rules established within the
	situations:		Geopriv Working Group that would categorize SIP as a 'using
			protocol' MUST be met [7]
	REQ UU1 - MUST work with dialog-initiating SIP Requests and		5. Requirements for UA-to-Proxy Server Location Conveyance
	responses, as well as the SIP MESSAGE method[4]
	REQ UU2 - the precision of resolution of the location given by the		The following are the requirements for UA-to-Proxy Server Location
	UAC is determined by the UAC, and SHOULD be based on who		Conveyance situations:
	the UAC is sending this location information to (most
	likely via local policy)
	REQ UU3 - UAC Location information SHOULD remain confidential in		U-PS1 - MUST work with dialog-initiating SIP Requests and
	route to the destination UA		responses, as well as the SIP MESSAGE method[4], and SHOULD
			work with most SIP messages.
	REQ UU4 - The privacy and security rules established within the		U-PS2 - UAC location information SHOULD remain confidential in
	Geopriv Working Group which would categorize SIP as a		route to the destination, but MUST be useable by
	'using protocol' MUST be followed [7]		intermediary proxy servers.
	REQ UU5 - The first sub-field must be what type of location		U-PS3 - The privacy and security rules established within the
	information it is (coordinate, civil, GPS, other)		Geopriv Working Group which would categorize SIP as a
			'using protocol' MUST be met [7]
	6. Requirements for Proxy-Routed Location Conveyance		U-PS4 - Modification or removal of the LO by proxy servers MUST NOT
			be required
	The following are the requirements for Proxy-Routed Location		U-PS5 - any mechanism used to prevent unwanted observation of this
	Conveyance situations:		Location Header(s) CANNOT fail the SIP Request if not
			understood by intermediary SIP entities or the destination
			UAS
	REQ PR1 - MUST work with dialog-initiating SIP Requests and		U-PS6 – It MUST be possible for a proxy server to assert the
	responses, as well as the SIP MESSAGE method[4]		validity of the location information provided by the UA.
			Alternatively, it is acceptable for there to be a mechanism
			for a proxy server to assert a location object itself.
	REQ PR2 - a mechanism SHOULD be in place to hide this location		6. Additional Requirements for Emergency Calls
	header from unwanted observation while in transit to,
	form, and among SIP intermediaries; but MUST NOT be
	mandatory for successful conveyance of location (don't
	want the SIP Request to fail without this mechanism used
	during emergencies)
	REQ PR3 - any mechanism used to prevent unwanted observation of		Emergency calls have requirements that are not generally important
	this Location Header(s) CANNOT fail the SIP Request if		to other uses for location in SIP:
	not understood by intermediary SIP entities or the
	destination UAS
	REQ PR4 - There SHOULD be a mechanism for the ERC to request the		Emergency calls presently have between 2 and 8-second call setup
	UAC's location information (perhaps more precise		times. There is ample evidence that the longer call setup end of
	location information) after the original SIP Request has		the range causes an unacceptable number of callers to abandon the
	been received without failing the original SIP Request		call before it is completed. Two-second call completion time is a
	(which is the most important aspect of this document:		goal of many existing emergency call centers. Allocating 25% of the
	that the session is received by the proper ERC)		call set up for processing privacy concerns seems reasonable; 1
			second would be 50% of the goal, which seems unacceptable; less than
			0.5 second seems unachievable, therefore:
	It is possible for a Proxy to determine the proper ERC to route		E-1 - Privacy mechanisms MUST add no more than 0.5 second of call
	the SIP Request to (based on the included location information		setup time when implemented in present technology UAs and
	within supplied by the UAC), yet create the situation where the		Proxy Servers.
	ERC does not know enough location information for personnel
	response to the emergency.
	REQ PR5 - A SIP location Header field (probably the first if there		It may be acceptable for full privacy mechanisms related to the
	is an order established to the headers) MUST be what		location of the UAC (and it's user) to be tried on an initial
	type of location information type it is (coordinate,		attempt to place a call, as long as the call attempt may be retried
	civil, GPS, other)		without the mechanism if the first attempt fails. Abandoning
			privacy in cases of failure of the privacy mechanism might be
			subject to user preference, although such a feature would be within
			the domain of a UA implementation and thus not subject to
			standardization. It should be noted that some jurisdictions have
			laws that explicitly deny any expectation of location privacy when
			making an emergency call.
	REQ PR6 - SHOULD have the complete location (coordinate or civil)		E-2 – Privacy mechanisms MUST NOT be mandatory for successful
	contained within a single header		conveyance of location during an (sos-type) emergency call.
	REQ PR7 - the most precise resolution (defined in [5])SHOULD be		E-3 – The retention and retransmission policy of the ERC must be
	given by the UAC when sending its location to an ERC (or		able to be made available to the user, and override the
	equivalent facility)		user's normal policy when local regulation governs such
			retention and retransmission. As in E-2 above, requiring the
			use of the ERC's retention and/or retransmission policy may
			be subject to user preference although in most jurisdictions,
			local laws specify such policies and may not be overridden by
			user preference.
	REQ PR8 - proxies SHOULD NOT partially remove location		7. Current Known Open issues
	information, but MAY remove it in its entirety when
	crossing a trust boundary to preserve privacy
	REQ PR9 - proxies MAY add location information unknown to the UAC		This is a list of open issues that have not yet been addressed to
	if known to the proxy		conclusion:
	REQ PR10 - if section 7.3.1 of [1] needs to be followed, the		- Whether self signed S/MIME bodies can work in both directions in
	Location Header SHOULD be near the top of the SIP		the emergency call scenario (to and from an ERC) as in [9]. It
	message header for rapid parsing purposes		appears that document covers self-signed certs from the UA to ERC
			direction, but it is not clear it solves communications in the
			reverse direction.
	REQ PR11 - mixed or additional location fields CAN be present		- If S/MIME is chosen as a SHOULD (in general, vs. TLS), this doc
	providing more precise location information, but MUST be		might consider stipulating a special purpose Proxy (an "emergency
	uniquely identifiable and SHOULD be relevant		services" proxy) that can process location information (a Geopriv
			LO) and route the message directly to the appropriate ERC.
	An example of this might be using the coordinate location		At Issue: plain "vanilla" proxies probably won't have the
	header and adding an identifiable cube or office number field		capabilities to route based on location information in the
	at the end of the coordinate header.		near future, but should that timing be considered here?
	7. Security Considerations		8. Security Considerations
	Conveyance of geo-location of a UAC is problematic for many reasons.		Conveyance of geo-location of a UAC is problematic for many reasons.
	This document calls for that conveyance to normally be accomplished		This document calls for that conveyance to normally be accomplished
	through secure message body means (like S/MIME). In cases where a		through secure message body means (like S/MIME or TLS). In cases
	session set-up is routed based on the location of the UAC initiating		where a session set-up is routed based on the location of the UAC
	the session or SIP MESSAGE, containing the location in a message		initiating the session or SIP MESSAGE, securing the location with an
	body does no good. At the same time, securing the location in a		end-to-end mechanism such as S/MIME is problematic.
	header might fail in certain times that is detrimental to that
	session (user). These times are those of emergency sessions (like to
	a US e911-like service).
	Although not advocated, this document therefore requires that
	location conveyance in deterministic times of emergency not be bound
	to being confidential universally, as that process might fail and
	could cost lives.
	8. IANA Considerations		9. IANA Considerations
	There are no IANA considerations within this document at this		There are no IANA considerations within this document at this time.
	time.
	9. Acknowledgements		10. Acknowledgements
	To Dave Oran for helping to shape this idea		To Dave Oran for helping to shape this idea. To Jon Peterson and
			Dean Willis on guidance of the effort.
	10. References - Normative		11. References - Normative
	[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.		[1] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J.
	Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session		Peterson, R. Sparks, M. Handley, E. Schooler, "SIP: Session
	Initiation Protocol ", RFC 3261, June 2002		Initiation Protocol ", RFC 3261, June 2002
	[2] S. Bradner, "Key words for use in RFCs to indicate requirement		[2] S. Bradner, "Key words for use in RFCs to indicate requirement
	levels," RFC 2119, Mar. 1997.		levels," RFC 2119, Mar. 1997.
	[3] H. Schulzrinne, "draft-schulzrinne-sipping-sos-04.txt", Internet		[3] H. Schulzrinne, "draft-schulzrinne-sipping-sos-04.txt", Internet
	Draft, Jan 03, Work in progress		Draft, Jan 03, Work in progress
	[4] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D.		[4] B. Campbell, Ed., J. Rosenberg, H. Schulzrinne, C. Huitema, D.
	Gurle, "Session Initiation Protocol (SIP) Extension for Instant		Gurle, "Session Initiation Protocol (SIP) Extension for Instant
	Messaging" , RFC 3428, December 2002		Messaging" , RFC 3428, December 2002
	[5] J. Polk, J. Schnizlein, M. Linsner, " draft-ietf-geopriv-dhcp-lci-		[5] J. Polk, J. Schnizlein, M. Linsner, " draft-ietf-geopriv-dhcp-lci-
	option-01.txt", Internet Draft, June 2003, Work in progress		option-02.txt", Internet Draft, Aug 2003, Work in progress
	[6] H. Schulzrinne, "draft-schulzrinne-geopriv-dhcp-civil-01.txt",		[6] H. Schulzrinne, "draft-schulzrinne-geopriv-dhcp-civil-01.txt",
	Internet Draft, Feb 03, Work in progress		Internet Draft, Feb 03, Work in progress
	[7] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "draft-		[7] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk, "draft-
	ietf-geopriv-reqs-03.txt", Internet Draft, Mar 03, Work in		ietf-geopriv-reqs-03.txt", Internet Draft, Mar 03, Work in
	progress		progress
	11. Author Information		[8] J. Rosenberg, "Requirements for Session Policy for the Session
			Initiation Protocol”, draft-ietf-sipping-session-policy-req-00",
			[9] C. Jennings, "draft-jennings-sipping-certs-01.txt", Internet
			Draft, "work in progress", July 2003
			12. Author Information
	James M. Polk		James M. Polk
	Cisco Systems		Cisco Systems
	2200 East President George Bush Turnpike		2200 East President George Bush Turnpike
	Richardson, Texas 75082 USA		Richardson, Texas 75082 USA
	jmpolk@cisco.com		jmpolk@cisco.com
	12. Full Copyright Statement		Brian Rosen
			Marconi Communications, Inc.
			2000 Marconi Drive
			Warrendale, PA 15086
			Brian.rosen@marconi.com
	"Copyright (C) The Internet Society (February 23rd, 2001).		"Copyright (C) The Internet Society (February 23rd, 2001).
	All Rights Reserved.		All Rights Reserved.
	This document and translations of it may be copied and furnished to		This document and translations of it may be copied and furnished to
	others, and derivative works that comment on or otherwise explain it		others, and derivative works that comment on or otherwise explain it
	or assist in its implementation may be prepared, copied, published		or assist in its implementation may be prepared, copied, published
	and distributed, in whole or in part, without restriction of any		and distributed, in whole or in part, without restriction of any
	kind, provided that the above copyright notice and this paragraph		kind, provided that the above copyright notice and this paragraph
	are included on all such copies and derivative works. However, this		are included on all such copies and derivative works. However, this
	skipping to change at page 9, line 36 ¶		skipping to change at page 8, line 48 ¶
	This document and the information contained herein is provided on an		This document and the information contained herein is provided on an
	"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING		"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
	TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING		TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
	BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION		BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
	HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF		HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
	MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."		MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
	The Expiration date for this Internet Draft is:		The Expiration date for this Internet Draft is:
	Dec 23rd, 2003		April 27th, 2004
End of changes. 54 change blocks.
	241 lines changed or deleted		201 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/