draft-ietf-httpbis-p4-conditional-09.txt		draft-ietf-httpbis-p4-conditional-10.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track Alcatel-Lucent
	Expires: September 9, 2010 J. Mogul		Expires: January 13, 2011 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	P. Leach		P. Leach
	Microsoft		Microsoft
	T. Berners-Lee		T. Berners-Lee
	W3C/MIT		W3C/MIT
	Y. Lafon, Ed.		Y. Lafon, Ed.
	W3C		W3C
	J. Reschke, Ed.		J. Reschke, Ed.
	greenbytes		greenbytes
	March 8, 2010		July 12, 2010
	HTTP/1.1, part 4: Conditional Requests		HTTP/1.1, part 4: Conditional Requests
	draft-ietf-httpbis-p4-conditional-09		draft-ietf-httpbis-p4-conditional-10
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia information
	systems. HTTP has been in use by the World Wide Web global		systems. HTTP has been in use by the World Wide Web global
	information initiative since 1990. This document is Part 4 of the		information initiative since 1990. This document is Part 4 of the
	seven-part specification that defines the protocol referred to as		seven-part specification that defines the protocol referred to as
	"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 4 defines
	request header fields for indicating conditional requests and the		request header fields for indicating conditional requests and the
	rules for constructing responses to those requests.		rules for constructing responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.10.		The changes in this draft are summarized in Appendix C.11.
	Status of this Memo		Status of This Memo
	This Internet-Draft is submitted to IETF in full conformance with the		This Internet-Draft is submitted in full conformance with the
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and 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). Note that other groups may also distribute
	other groups may also distribute working documents as Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	The list of current Internet-Drafts can be accessed at		This Internet-Draft will expire on January 13, 2011.
	http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on September 9, 2010.
	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
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the BSD License.		described in the Simplified BSD License.
	This document may contain material from IETF Documents or IETF		This document may contain material from IETF Documents or IETF
	Contributions published or made publicly available before November		Contributions published or made publicly available before November
	10, 2008. The person(s) controlling the copyright in some of this		10, 2008. The person(s) controlling the copyright in some of this
	material may not have granted the IETF Trust the right to allow		material may not have granted the IETF Trust the right to allow
	modifications of such material outside the IETF Standards Process.		modifications of such material outside the IETF Standards Process.
	Without obtaining an adequate license from the person(s) controlling		Without obtaining an adequate license from the person(s) controlling
	the copyright in such materials, this document may not be modified		the copyright in such materials, this document may not be modified
	outside the IETF Standards Process, and derivative works of it may		outside the IETF Standards Process, and derivative works of it may
	not be created outside the IETF Standards Process, except to format		not be created outside the IETF Standards Process, except to format
	skipping to change at page 3, line 14		skipping to change at page 3, line 14
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 5
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 5		Specification . . . . . . . . . . . . . . . . . . . . 5
	2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Entity Tags . . . . . . . . . . . . . . . . . . . . . . . . . 5
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6		2.1. Example: Entity Tags varying on Content-Negotiated
	3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 6		Resources . . . . . . . . . . . . . . . . . . . . . . . . 6
	3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 6		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
	4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 7		3.1. 304 Not Modified . . . . . . . . . . . . . . . . . . . . . 7
	5. Rules for When to Use Entity Tags and Last-Modified Dates . . 9		3.2. 412 Precondition Failed . . . . . . . . . . . . . . . . . 8
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 11		4. Weak and Strong Validators . . . . . . . . . . . . . . . . . . 8
	6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 11		5. Rules for When to Use Entity Tags and Last-Modified Dates . . 11
	6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 12		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 12
	6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 13		6.1. ETag . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 15		6.2. If-Match . . . . . . . . . . . . . . . . . . . . . . . . . 13
	6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 16		6.3. If-Modified-Since . . . . . . . . . . . . . . . . . . . . 14
	6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 17		6.4. If-None-Match . . . . . . . . . . . . . . . . . . . . . . 16
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17		6.5. If-Unmodified-Since . . . . . . . . . . . . . . . . . . . 17
	7.1. Status Code Registration . . . . . . . . . . . . . . . . . 17		6.6. Last-Modified . . . . . . . . . . . . . . . . . . . . . . 18
	7.2. Message Header Registration . . . . . . . . . . . . . . . 18		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 18		7.1. Status Code Registration . . . . . . . . . . . . . . . . . 19
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		7.2. Message Header Registration . . . . . . . . . . . . . . . 19
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 18		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19
	10.2. Informative References . . . . . . . . . . . . . . . . . . 19		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Appendix A. Compatibility with Previous Versions . . . . . . . . 19		10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 19		10.2. Informative References . . . . . . . . . . . . . . . . . . 20
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 20		Appendix A. Compatibility with Previous Versions . . . . . . . . 20
			A.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20
			Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 20		publication) . . . . . . . . . . . . . . . . . . . . 21
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 20		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 21
	C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 21		C.2. Since draft-ietf-httpbis-p4-conditional-00 . . . . . . . . 22
	C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 21		C.3. Since draft-ietf-httpbis-p4-conditional-01 . . . . . . . . 22
	C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 21		C.4. Since draft-ietf-httpbis-p4-conditional-02 . . . . . . . . 22
	C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 21		C.5. Since draft-ietf-httpbis-p4-conditional-03 . . . . . . . . 22
	C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 22		C.6. Since draft-ietf-httpbis-p4-conditional-04 . . . . . . . . 23
	C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 22		C.7. Since draft-ietf-httpbis-p4-conditional-05 . . . . . . . . 23
	C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 22		C.8. Since draft-ietf-httpbis-p4-conditional-06 . . . . . . . . 23
	C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 22		C.9. Since draft-ietf-httpbis-p4-conditional-07 . . . . . . . . 23
	C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 22		C.10. Since draft-ietf-httpbis-p4-conditional-08 . . . . . . . . 23
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		C.11. Since draft-ietf-httpbis-p4-conditional-09 . . . . . . . . 23
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 response metadata for indicating		This document defines HTTP/1.1 response metadata for indicating
	potential changes to payload content, including modification time		potential changes to payload content, including modification time
	stamps and opaque entity-tags, and the HTTP conditional request		stamps and opaque entity-tags, and the HTTP conditional request
	mechanisms that allow preconditions to be placed on a request method.		mechanisms that allow preconditions to be placed on a request method.
	Conditional GET requests allow for efficient cache updates. Other		Conditional GET requests allow for efficient cache updates. Other
	conditional request methods are used to protect against overwriting		conditional request methods are used to protect against overwriting
	or misunderstanding the state of a resource that has been changed		or misunderstanding the state of a resource that has been changed
	skipping to change at page 4, line 35		skipping to change at page 4, line 35
	mess reflects how widely dispersed these topics and associated		mess reflects how widely dispersed these topics and associated
	requirements had become in [RFC2616].		requirements had become in [RFC2616].
	1.1. Requirements		1.1. Requirements
	The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",		The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
	"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].
	An implementation is not compliant if it fails to satisfy one or more		An implementation is not compliant if it fails to satisfy one or more
	of the MUST or REQUIRED level requirements for the protocols it		of the "MUST" or "REQUIRED" level requirements for the protocols it
	implements. An implementation that satisfies all the MUST or		implements. An implementation that satisfies all the "MUST" or
	REQUIRED level and all the SHOULD level requirements for its		"REQUIRED" level and all the "SHOULD" level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the "MUST" level requirements but not all the "SHOULD"
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant".
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the ABNF syntax defined in Section 1.2 of		This specification uses the ABNF syntax defined in Section 1.2 of
	[Part1] (which extends the syntax defined in [RFC5234] with a list		[Part1] (which extends the syntax defined in [RFC5234] with a list
	rule). Appendix B shows the collected ABNF, with the list rule		rule). Appendix B shows the collected ABNF, with the list rule
	expanded.		expanded.
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF		[RFC5234], Appendix B.1: ALPHA (letters), CR (carriage return), CRLF
	skipping to change at page 6, line 5		skipping to change at page 6, line 5
	could be substituted for each other with no significant change in		could be substituted for each other with no significant change in
	semantics. A weak entity tag can only be used for weak comparison.		semantics. A weak entity tag can only be used for weak comparison.
	An entity tag MUST be unique across all versions of all entities		An entity tag MUST be unique across all versions of all entities
	associated with a particular resource. A given entity tag value MAY		associated with a particular resource. A given entity tag value MAY
	be used for entities obtained by requests on different URIs. The use		be used for entities obtained by requests on different URIs. The use
	of the same entity tag value in conjunction with entities obtained by		of the same entity tag value in conjunction with entities obtained by
	requests on different URIs does not imply the equivalence of those		requests on different URIs does not imply the equivalence of those
	entities.		entities.
			2.1. Example: Entity Tags varying on Content-Negotiated Resources
			Consider a resource that is subject to content negotiation (Section 4
			of [Part3]), and where the representations returned upon a GET
			request vary based on the Accept-Encoding request header field
			(Section 5.3 of [Part3]):
			>> Request:
			GET /index HTTP/1.1
			Host: www.example.com
			Accept-Encoding: gzip
			In this case, the response may use the gzip Content Coding or not.
			If it does, it might look like that:
			>> Response:
			HTTP/1.1 200 OK
			Date: Thu, 26 Mar 2010 00:05:00 GMT
			ETag: "123-a"
			Content-Length: 70
			Vary: Accept-Encoding
			Content-Type: text/plain
			Hello World!
			Hello World!
			Hello World!
			Hello World!
			Hello World!
			A variant that does use gzip Content Coding would be:
			>> Response:
			HTTP/1.1 200 OK
			Date: Thu, 26 Mar 2010 00:05:00 GMT
			ETag: "123-b"
			Content-Length: 43
			Vary: Accept-Encoding
			Content-Type: text/plain
			Content-Encoding: gzip
			...binary data...
			Note: Content Codings are a property of the response entity, thus
			affect the Entity Tag. An alternative are Transfer Codings
			(Section 6.2 of [Part1]) which apply only to the transfer of the
			message, and thus do not require assigning distinct entity tags.
	3. Status Code Definitions		3. Status Code Definitions
	3.1. 304 Not Modified		3.1. 304 Not Modified
	If the client has performed a conditional GET request and access is		If the client has performed a conditional GET request and access is
	allowed, but the document has not been modified, the server SHOULD		allowed, but the document has not been modified, the server SHOULD
	respond with this status code. The 304 response MUST NOT contain a		respond with this status code. The 304 response MUST NOT contain a
	message-body, and thus is always terminated by the first empty line		message-body, and thus is always terminated by the first empty line
	after the header fields.		after the header fields.
	skipping to change at page 18, line 46		skipping to change at page 20, line 5
	9. Acknowledgments		9. Acknowledgments
	10. References		10. References
	10.1. Normative References		10.1. Normative References
	[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part1] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,		and J. Reschke, Ed., "HTTP/1.1, part 1: URIs, Connections,
	and Message Parsing", draft-ietf-httpbis-p1-messaging-09		and Message Parsing", draft-ietf-httpbis-p1-messaging-10
	(work in progress), March 2010.		(work in progress), July 2010.
			[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
			Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
			and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
			and Content Negotiation", draft-ietf-httpbis-p3-payload-10
			(work in progress), July 2010.
	[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part5] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and		and J. Reschke, Ed., "HTTP/1.1, part 5: Range Requests and
	Partial Responses", draft-ietf-httpbis-p5-range-09 (work		Partial Responses", draft-ietf-httpbis-p5-range-10 (work
	in progress), March 2010.		in progress), July 2010.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	6: Caching", draft-ietf-httpbis-p6-cache-09 (work in		6: Caching", draft-ietf-httpbis-p6-cache-10 (work in
	progress), March 2010.		progress), July 2010.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, March 1997.		Requirement Levels", BCP 14, RFC 2119, March 1997.
	[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax		[RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
	Specifications: ABNF", STD 68, RFC 5234, January 2008.		Specifications: ABNF", STD 68, RFC 5234, January 2008.
	10.2. Informative References		10.2. Informative References
	[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,		[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
	skipping to change at page 22, line 48		skipping to change at page 23, line 48
	non-GET requests" (If-Match still was defined to require strong		non-GET requests" (If-Match still was defined to require strong
	matching)		matching)
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA		o <http://tools.ietf.org/wg/httpbis/trac/ticket/198>: "move IANA
	registrations for optional status codes"		registrations for optional status codes"
	C.10. Since draft-ietf-httpbis-p4-conditional-08		C.10. Since draft-ietf-httpbis-p4-conditional-08
	No significant changes.		No significant changes.
			C.11. Since draft-ietf-httpbis-p4-conditional-09
			No significant changes.
	Index		Index
	3		3
	304 Not Modified (status code) 6		304 Not Modified (status code) 7
	4		4
	412 Precondition Failed (status code) 6		412 Precondition Failed (status code) 8
	E		E
	ETag header 11		ETag header 13
	G		G
	Grammar		Grammar
	entity-tag 5		entity-tag 5
	ETag 11		ETag 13
	ETag-v 11		ETag-v 13
	If-Match 12		If-Match 13
	If-Match-v 12		If-Match-v 13
	If-Modified-Since 13		If-Modified-Since 15
	If-Modified-Since-v 13		If-Modified-Since-v 15
	If-None-Match 15		If-None-Match 16
	If-None-Match-v 15		If-None-Match-v 16
	If-Unmodified-Since 16		If-Unmodified-Since 17
	If-Unmodified-Since-v 16		If-Unmodified-Since-v 17
	Last-Modified 17		Last-Modified 18
	Last-Modified-v 17		Last-Modified-v 18
	opaque-tag 5		opaque-tag 5
	weak 5		weak 5
	H		H
	Headers		Headers
	ETag 11		ETag 13
	If-Match 12		If-Match 13
	If-Modified-Since 13		If-Modified-Since 14
	If-None-Match 15		If-None-Match 16
	If-Unmodified-Since 16		If-Unmodified-Since 17
	Last-Modified 17		Last-Modified 18
	I		I
	If-Match header 12		If-Match header 13
	If-Modified-Since header 13		If-Modified-Since header 14
	If-None-Match header 15		If-None-Match header 16
	If-Unmodified-Since header 16		If-Unmodified-Since header 17
	L		L
	Last-Modified header 17		Last-Modified header 18
	S		S
	Status Codes		Status Codes
	304 Not Modified 6		304 Not Modified 7
	412 Precondition Failed 6		412 Precondition Failed 8
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Day Software		Day Software
	23 Corporate Plaza DR, Suite 280		23 Corporate Plaza DR, Suite 280
	Newport Beach, CA 92660		Newport Beach, CA 92660
	USA		USA
	Phone: +1-949-706-5300		Phone: +1-949-706-5300
	Fax: +1-949-706-5305		Fax: +1-949-706-5305
	Email: fielding@gbiv.com		EMail: fielding@gbiv.com
	URI: http://roy.gbiv.com/		URI: http://roy.gbiv.com/
	Jim Gettys		Jim Gettys
	One Laptop per Child		Alcatel-Lucent Bell Labs
	21 Oak Knoll Road		21 Oak Knoll Road
	Carlisle, MA 01741		Carlisle, MA 01741
	USA		USA
	Email: jg@laptop.org		EMail: jg@freedesktop.org
	URI: http://www.laptop.org/		URI: http://gettys.wordpress.com/
	Jeffrey C. Mogul		Jeffrey C. Mogul
	Hewlett-Packard Company		Hewlett-Packard Company
	HP Labs, Large Scale Systems Group		HP Labs, Large Scale Systems Group
	1501 Page Mill Road, MS 1177		1501 Page Mill Road, MS 1177
	Palo Alto, CA 94304		Palo Alto, CA 94304
	USA		USA
	Email: JeffMogul@acm.org		EMail: JeffMogul@acm.org
	Henrik Frystyk Nielsen		Henrik Frystyk Nielsen
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	USA		USA
	Email: henrikn@microsoft.com		EMail: henrikn@microsoft.com
	Larry Masinter		Larry Masinter
	Adobe Systems, Incorporated		Adobe Systems, Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	Email: LMM@acm.org		EMail: LMM@acm.org
	URI: http://larry.masinter.net/		URI: http://larry.masinter.net/
	Paul J. Leach		Paul J. Leach
	Microsoft Corporation		Microsoft Corporation
	1 Microsoft Way		1 Microsoft Way
	Redmond, WA 98052		Redmond, WA 98052
	Email: paulle@microsoft.com		EMail: paulle@microsoft.com
	Tim Berners-Lee		Tim Berners-Lee
	World Wide Web Consortium		World Wide Web Consortium
	MIT Computer Science and Artificial Intelligence Laboratory		MIT Computer Science and Artificial Intelligence Laboratory
	The Stata Center, Building 32		The Stata Center, Building 32
	32 Vassar Street		32 Vassar Street
	Cambridge, MA 02139		Cambridge, MA 02139
	USA		USA
	Email: timbl@w3.org		EMail: timbl@w3.org
	URI: http://www.w3.org/People/Berners-Lee/		URI: http://www.w3.org/People/Berners-Lee/
	Yves Lafon (editor)		Yves Lafon (editor)
	World Wide Web Consortium		World Wide Web Consortium
	W3C / ERCIM		W3C / ERCIM
	2004, rte des Lucioles		2004, rte des Lucioles
	Sophia-Antipolis, AM 06902		Sophia-Antipolis, AM 06902
	France		France
	Email: ylafon@w3.org		EMail: ylafon@w3.org
	URI: http://www.raubacapeu.net/people/yves/		URI: http://www.raubacapeu.net/people/yves/
	Julian F. Reschke (editor)		Julian F. Reschke (editor)
	greenbytes GmbH		greenbytes GmbH
	Hafenweg 16		Hafenweg 16
	Muenster, NW 48155		Muenster, NW 48155
	Germany		Germany
	Phone: +49 251 2807760		Phone: +49 251 2807760
	Fax: +49 251 2807761		Fax: +49 251 2807761
	Email: julian.reschke@greenbytes.de		EMail: julian.reschke@greenbytes.de
	URI: http://greenbytes.de/tech/webdav/		URI: http://greenbytes.de/tech/webdav/
End of changes. 38 change blocks.
	105 lines changed or deleted		161 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/