< draft-ietf-geopriv-dhcp-lbyr-uri-option-08.txt		draft-ietf-geopriv-dhcp-lbyr-uri-option-09.txt >
	Geopriv WG James Polk		Geopriv WG James Polk
	Internet-Draft Cisco Systems		Internet-Draft Cisco Systems
	Intended status: Standards Track (PS) July 28, 2010		Intended status: Standards Track (PS) Oct 13, 2010
	Expires: January 28, 2011		Expires: April 13, 2011
	Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6		Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6
	Option for a Location Uniform Resource Identifier (URI)		Option for a Location Uniform Resource Identifier (URI)
	draft-ietf-geopriv-dhcp-lbyr-uri-option-08		draft-ietf-geopriv-dhcp-lbyr-uri-option-09
	Abstract		Abstract
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for transmitting a client's geolocation Uniform Resource		Option for transmitting a client's geolocation Uniform Resource
	Identifier (URI) of a client, which can be dereferenced in a		Identifier (URI) of a client, which can be dereferenced in a
	separate transaction by the client or an entity the client sends		separate transaction by the client or an entity the client sends
	this URI to.		this URI to.
	Status of this Memo		Status of this Memo
	skipping to change at page 1, line 40 ¶		skipping to change at page 1, line 40 ¶
	months and may be updated, replaced, or obsoleted by other documents		months and may be updated, replaced, or obsoleted by other documents
	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 progress."		reference material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 28, 2011.		This Internet-Draft will expire on April 13, 2011.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 38 ¶		skipping to change at page 2, line 38 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	1. Introduction		1. Introduction
	This document creates a Dynamic Host Configuration Protocol (DHCP)		This document creates a Dynamic Host Configuration Protocol (DHCP)
	Option for transmitting a client's geolocation Uniform Resource		Option for transmitting a client's geolocation Uniform Resource
	Identifier (URI). The DHCP implementation of the client can then		Identifier (URI). The DHCP implementation of the client can then
	make this location information available to upper layer protocols		make this location information available to upper layer protocols
	for their usage. This location URI points a Location Server		for their usage. This location URI points a Location Server
	[ID-LBYR-REQ] which has the geolocation of the client (through means		[RFC5808] which has the geolocation of the client (through means
	not defined in this document). In this scenario, the DHCP client		not defined in this document). In this scenario, the DHCP client
	is a Geopriv Target (i.e., the entity whose geolocation is		is a Geopriv Target (i.e., the entity whose geolocation is
	associated by the location URI).		associated by the location URI).
	Applications using upper layer protocols within the Target can then		Applications using upper layer protocols within the Target can then
	choose to deference this location URI and/or transmit the URI to		choose to deference this location URI and/or transmit the URI to
	another entity as a means of conveying where the Target is located.		another entity as a means of conveying where the Target is located.
	Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying		Dereferencing a location URI is described in [ID-SIP-LOC]. Conveying
	a location URI is also described in [ID-SIP-LOC]. Session Initiation		a location URI is also described in [ID-SIP-LOC]. Session Initiation
	Protocol (SIP) is not the only protocol that can dereference a		Protocol (SIP) is not the only protocol that can dereference a
	skipping to change at page 4, line 45 ¶		skipping to change at page 4, line 45 ¶
	2. Format of the DHCP LuriElement Option		2. Format of the DHCP LuriElement Option
	2.1 Overall Format of LuriElement Option in IPv4		2.1 Overall Format of LuriElement Option in IPv4
	The LuriElement Option format for IPv4 is as follows:		The LuriElement Option format for IPv4 is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Code XXX | Length=XX | Ver | Resv | .		| Code XXX | Length=XX | .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
	. LuriElements... ...		. LuriElements... ...
	. (see Section 2.3 for details) ... .		. (see Section 2.3 for details) ... |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 1. IPv4 Fields for this LuriElement Option		Figure 1. IPv4 Fields for this LuriElement Option
	Code XXX: The code for this DHCPv4 option (IANA assigned).		Code XXX: The code for this DHCPv4 option (IANA assigned).
	Length=XX: The length of this option, counted in bytes - not		Length=XX: The length of this option, counted in bytes - not
	counting the Code and Length bytes. This is a variable		counting the Code and Length bytes. This is a variable
	length Option, therefore the length value will change		length Option, therefore the length value will change
	based on the length of the URI within the Option.		based on the length of the URI within the Option.
	Ver: (4 bits) The version of this Option. This document
	defines version 1 of this Option.
	Resv: (4 bits) reserved for future use.
	LuriElement: see Section 2.3 for details		LuriElement: see Section 2.3 for details
	2.2 Overall Format of LuriElement Option in IPv6		2.2 Overall Format of LuriElement Option in IPv6
	The LuriElement Option format for IPv6 is as follows:		The LuriElement Option format for IPv6 is as follows:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| option-code | option-len |		| option-code | option-len |
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	| Ver | Resv | .		| LuriElements... .
	+---------------+ .		. (see Section 2.3 for details) |
	. LuriElements... .
	. (see Section 2.3 for details) .
	+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+		+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
	Figure 2. IPv6 fields of this LuriElement Option		Figure 2. IPv6 fields of this LuriElement Option
	option-code: The code for this DHCPv6 option (IANA assigned).		option-code: The code for this DHCPv6 option (IANA assigned).
	option-len: The length of this option, counted in bytes - not		option-len: The length of this option, counted in bytes - not
	counting the Code and Length bytes. This is a variable		counting the Code and Length bytes. This is a variable
	length Option, therefore the length value will change		length Option, therefore the length value will change
	based on the shape within the Option.		based on the length of the URI within the Option.
	Ver: See above (Section 2.1). This will specify version 1.
	Resv: See above (Section 2.1).
	LuriElement: see below (Section 2.3 for details).		LuriElement: see below (Section 2.3 for details).
	2.3 LuriElement Format for both IPv4 and IPv6		2.3 LuriElement Format for both IPv4 and IPv6
	The LuriElement, in both DHCPv4 and DHCPv6, have the following		The LuriElement, in both DHCPv4 and DHCPv6, have the following
	format:		format:
	0 1 2 3		0 1 2 3
	0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1		0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
	skipping to change at page 6, line 32 ¶		skipping to change at page 6, line 19 ¶
	The LuriTypes this document defines (and IANA registers) for a point		The LuriTypes this document defines (and IANA registers) for a point
	are:		are:
	LuriType=1 Location URI - This is the URI pointing at the		LuriType=1 Location URI - This is the URI pointing at the
	location record where the PIDF-LO resides which		location record where the PIDF-LO resides which
	indicates the location of the Location Target.		indicates the location of the Location Target.
	LuriType=2 Valid-For - The time, in seconds, this URI is to be		LuriType=2 Valid-For - The time, in seconds, this URI is to be
	considered Valid for dereferencing. The timer		considered Valid for dereferencing. The timer
	associated with this LuriType starts upon receipt of		associated with this LuriType starts upon receipt of
	this Option.		this Option by the client.
	The LuriType=2 (Valid-For) indicates how long, in seconds, the		The LuriType=2 (Valid-For) indicates how long, in seconds, the
	client is to consider this LuriType=1 (location URI) valid		client is to consider this LuriType=1 (location URI) valid
	before performing a refresh of this Option, with a refreshed		before performing a refresh of this Option, with a refreshed
	LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done		LuriType=2 (Valid-For) value. A Location URI refresh SHOULD be done
	the normal DHCP refresh rate, or necessitated by this timer, perhaps		the normal DHCP refresh rate, or necessitated by this timer, perhaps
	with the client only requesting this Option be refreshed.		with the client only requesting this Option be refreshed.
	If the LuriType=2 (Valid-For) timer is received (solicited or		If the LuriType=2 (Valid-For) timer is received (solicited or
	unsolicited), it is RECOMMENDED that the client refresh the Location		unsolicited), it is RECOMMENDED that the client refresh the Location
	URI when the (Valid-For) counter value has reaches the halfway		URI when the (Valid-For) counter value has reaches the halfway
	point. For example, if 16000 was the initial value of the		point. For example, if 16000 was the initial value of the
	LuriType=2 (Valid-For) value, when 8000 seconds have passed, the		LuriType=2 (Valid-For) value, when 8000 seconds have passed, the
	Option SHOULD be refreshed.		Option SHOULD be refreshed.
	The LuriType=2 (Valid-For) is not mandated for use by this document.		The LuriType=2 (Valid-For) is not mandated for use by this document.
	However, its presence MUST NOT cause any error in handling the		However, its presence MUST NOT cause any error in handling the
	location URI (i.e., if not understood, it MUST be ignored).		location URI (i.e., if not understood, it MUST be ignored).
	This Option format is highly extensible. Additional LuriType types		This Option format is highly extensible. Additional LuriType types
	created MUST be done so through IANA registration with peer review		created MUST be done so through IANA registration with a standards
	and an RFC.		track RFC.
	3. DHC Option Operation		3. DHC Option Operation
	The [RFC3046] RAIO MUST be utilized to provide the appropriate		The [RFC3046] RAIO can be utilized to provide the appropriate
	indication to the DHCP Server where this DISCOVER or REQUEST message		indication to the DHCP Server where this DISCOVER or REQUEST message
	came from, in order to supply the correct response. That said, this		came from, in order to supply the correct response.
	Option SHOULD NOT be in a DISCOVER message, because there is zero
	knowledge by the client of which Server will answer.
	Caution SHOULD always be used involving the creation of large		Caution SHOULD always be used involving the creation of large
	Options, meaning that this Option MAY need to be in its own INFORM,		Options, meaning that this Option MAY need to be in its own INFORM,
	OPTION or ACK message.		OPTION or ACK message.
	It is RECOMMENDED to avoid building URIs, with any parameters,		It is RECOMMENDED to avoid building URIs, with any parameters,
	larger than what a single DHCP response can be. However, if a		larger than what a single DHCP response can be. However, if a
	message is larger than 255 bytes, concatenation is allowed, per RFC		message is larger than 255 bytes, concatenation is allowed, per RFC
	3396 [RFC3396].		3396 [RFC3396].
	skipping to change at page 8, line 24 ¶		skipping to change at page 8, line 11 ¶
	The following assumptions have been made for use of this LuriElement		The following assumptions have been made for use of this LuriElement
	Option for a client to learn its location URI (in no particular		Option for a client to learn its location URI (in no particular
	order):		order):
	o Any user control (what [RFC3693] calls a 'Ruleholder') for access		o Any user control (what [RFC3693] calls a 'Ruleholder') for access
	to the dereferencing step is assumed to be out of scope of this		to the dereferencing step is assumed to be out of scope of this
	document. An example authorization policy is in [ID-GEO-POL].		document. An example authorization policy is in [ID-GEO-POL].
	o The authorization vs. possession security model can be found in		o The authorization vs. possession security model can be found in
	[ID-LBYR-REQ], describing what is expected in each model of		[RFC5808], describing what is expected in each model of
	operation. It should be assumed that a location URI attained		operation. It should be assumed that a location URI attained
	using DHCP will operate under an authorization model. This means		using DHCP will operate under an authorization model. This means
	possessing the location URI does not give that entity the right		possessing the location URI does not give that entity the right
	to view the PIDF-LO of the target whose location is indicated in		to view the PIDF-LO of the target whose location is indicated in
	a presence document. The dereference transaction will be, in		a presence document. The dereference transaction will be, in
	many environments, challenged by the Location Server. The nature		many environments, challenged by the Location Server. The nature
	of this challenge is out of scope of this document.		of this challenge is out of scope of this document.
	o This document does not prevent some environments from operating		o This document does not prevent some environments from operating
	in a possession model, for example - tightly controlled		in a possession model, for example - tightly controlled
	skipping to change at page 9, line 45 ¶		skipping to change at page 9, line 32 ¶
	4.1 The IPv4 Option number for this Option		4.1 The IPv4 Option number for this Option
	This document IANA registers this IPv4 Option number XXX (to be		This document IANA registers this IPv4 Option number XXX (to be
	assigned by IANA once this document becomes an RFC).		assigned by IANA once this document becomes an RFC).
	4.2 The IPv6 Option-Code for this Option		4.2 The IPv6 Option-Code for this Option
	This document IANA registers this IPv6 Option-Code XXX (to be		This document IANA registers this IPv6 Option-Code XXX (to be
	assigned by IANA once this document becomes an RFC).		assigned by IANA once this document becomes an RFC).
	4.3 The Version number for this Option		4.3 IANA Considerations for Acceptable Location URI Types
	This document IANA registers the version number 1 of this Option.
	4.4 IANA Considerations for Acceptable Location URI Types
	IANA is requested to create a new registry for acceptable location		IANA is requested to create a new registry for acceptable location
	URI types.		URI types.
	The following 3 URI types are registered by this document:		The following 3 URI types are registered by this document:
	1. sip:		1. sip:
	2. sips:		2. sips:
	3. pres:		3. pres:
	4. http:		4. http:
	5. https:		5. https:
	Any additional location URI types to be defined for use via		Any additional location URI types to be defined for use via
	this DHC Option need to be created and IANA registered with peer		this DHC Option need to be created and IANA registered with peer
	review and an RFC.		review and an RFC.
	4.5 IANA Considerations for LuriTypes		4.4 IANA Considerations for LuriTypes
	IANA is requested to create a new registry for acceptable location		IANA is requested to create a new registry for acceptable location
	types defined in Section 3.2 of this document, arranged similar to		types defined in Section 3.2 of this document, arranged similar to
	this:		this:
	+------------+----------------------------------------+-----------+		+------------+----------------------------------------+-----------+
	| LuriType | Name | Reference |		| LuriType | Name | Reference |
	+------------+----------------------------------------+-----------+		+------------+----------------------------------------+-----------+
	| 1 | Location URI | RFC XXXX* |		| 1 | Location URI | RFC XXXX* |
	| 2 | Valid-For | RFC XXXX* |		| 2 | Valid-For | RFC XXXX* |
	+------------+----------------------------------------+-----------+		+------------+----------------------------------------+-----------+
	* RFC XXXX is to be replaced with this document's RFC-Editor RFC		* RFC XXXX is to be replaced with this document's RFC-Editor RFC
	number.		number.
	Additions to this list require a standards track RFC.		Additions to this registry require a standards track RFC.
	5. Security Considerations		5. Security Considerations
	Where critical decisions might be based on the value of this		Where critical decisions might be based on the value of this
	location URI option, DHCP authentication in [RFC3118] SHOULD be used		location URI option, DHCP authentication in [RFC3118] SHOULD be used
	to protect the integrity of the DHCP options.		to protect the integrity of the DHCP options.
	A real concern with RFC 3118 it is that not widely deployed because		A real concern with RFC 3118 it is that not widely deployed because
	it requires pre-shared keys to successfully work (i.e., in the		it requires pre-shared keys to successfully work (i.e., in the
	client and in the server). Most implementations do not		client and in the server). Most implementations do not
	skipping to change at page 12, line 25 ¶		skipping to change at page 12, line 5 ¶
	[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,		[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
	March 1997.		March 1997.
	[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP		[RFC3118] Droms, R. and W. Arbaugh, "Authentication for DHCP
	Messages", RFC 3118, June 2001.		Messages", RFC 3118, June 2001.
	[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.
	[RFC3265] Roach, A., "Session Initiation Protocol (SIP)-Specific
	Event Notification", RFC 3265, June 2002.
	[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic		[RFC3396] T. Lemon, S. Cheshire, "Encoding Long Options in the Dynamic
	Host Configuration Protocol (DHCPv4)", RFC 3396, November		Host Configuration Protocol (DHCPv4)", RFC 3396, November
	2002		2002
	[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
	[RFC3856] J. Rosenberg, "A Presence Event Package for the Session		[RFC3856] J. Rosenberg, "A Presence Event Package for the Session
	Initiation Protocol (SIP)", RFC 3856, August 2004		Initiation Protocol (SIP)", RFC 3856, August 2004
	[RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference		[RFC5808] R. Marshall, Ed., "Requirements for a Location-by-Reference
	Mechanism", RFC 5808, May 2010		Mechanism", RFC 5808, May 2010
	7.2. Informative References		7.2. Informative References
	[ID-SIP-LOC] J. Polk, B. Rosen, "SIP Location Conveyance", "work in		[ID-SIP-LOC] J. Polk, B. Rosen, J. Peterson, "SIP Location
	progress", Feb 2010		Conveyance", "work in progress", July 2010
	[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.		[ID-HELD-DEREF] J. Winterbottom, H. Tschofenig, H. Schulzrinne, M.
	Thomson, M. Dawson, "A Location Dereferencing Protocol Using		Thomson, M. Dawson, "A Location Dereferencing Protocol Using
	HELD", "work in progress", January 2010		HELD", "work in progress", January 2010
	[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
	[RFC4776] 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 ", RFC 4776, November 2006		Information ", RFC 4776, November 2006
	[ID-LBYR-REQ] R. Marshall, "Requirements for a Location-by-Reference		[RFC5808] R. Marshall, "Requirements for a Location-by-Reference
	Mechanism", "work in progress", November 2009		Mechanism", RFC 5808, May 2010
	[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,		[RFC3693] J. Cuellar, J. Morris, D. Mulligan, J. Peterson. J. Polk,
	"Geopriv Requirements", RFC 3693, February 2004		"Geopriv Requirements", RFC 3693, February 2004
	[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.		[ID-GEO-POL] H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.
	Polk, "Geolocation Policy: A Document Format for Expressing		Polk, "Geolocation Policy: A Document Format for Expressing
	Privacy Preferences for Location Information", "work in		Privacy Preferences for Location Information", "work in
	progress", July 2009		progress", July 2010
	[RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of		[RFC5606] J. Peterson, T. Hardie, J. Morris, " Implications of
	'retransmission-allowed' for SIP Location Conveyance",		'retransmission-allowed' for SIP Location Conveyance",
	August 2009		August 2009
	[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,		[RFC2616] R. Fielding, J. Gettys, J., Mogul, H. Frystyk, L.,
	Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer		Masinter, P. Leach, T. Berners-Lee, "Hypertext Transfer
	Protocol - HTTP/1.1", RFC 2616, June 1999		Protocol - HTTP/1.1", RFC 2616, June 1999
	[ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location		[ID-POLICY-URI] R. Barnes, M. Thomson, J. Winterbottom, "Location
End of changes. 21 change blocks.
	45 lines changed or deleted		25 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/