draft-ietf-httpbis-p2-semantics-06.txt		draft-ietf-httpbis-p2-semantics-07.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
	Updates: 2817 (if approved) One Laptop per Child		Updates: 2817 (if approved) One Laptop per Child
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: September 10, 2009 HP		Expires: January 14, 2010 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 9, 2009		July 13, 2009
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-06		draft-ietf-httpbis-p2-semantics-07
	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 to IETF in full conformance with the
	provisions of BCP 78 and BCP 79. This document may contain material		provisions of BCP 78 and BCP 79. This document may contain material
	from IETF Documents or IETF Contributions published or made publicly		from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the		available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF		copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the		Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from		IETF Standards Process. Without obtaining an adequate license from
	skipping to change at page 2, line 10		skipping to change at page 2, line 10
	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		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 September 10, 2009.		This Internet-Draft will expire on January 14, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2009 IETF Trust and the persons identified as the		Copyright (c) 2009 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 in effect on the date of		Provisions Relating to IETF Documents in effect on the date of
	publication of this document (http://trustee.ietf.org/license-info).		publication of this document (http://trustee.ietf.org/license-info).
	Please review these documents carefully, as they describe your rights		Please review these documents carefully, as they describe your rights
	skipping to change at page 2, line 43		skipping to change at page 2, line 43
	fields.		fields.
	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/11> 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.7.		The changes in this draft are summarized in Appendix C.8.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 6
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 6
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 7
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 7		Specification . . . . . . . . . . . . . . . . . . . . 7
	2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8		2. Method . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
	skipping to change at page 5, line 12		skipping to change at page 5, line 12
	13.1. Normative References . . . . . . . . . . . . . . . . . . . 41		13.1. Normative References . . . . . . . . . . . . . . . . . . . 41
	13.2. Informative References . . . . . . . . . . . . . . . . . . 42		13.2. Informative References . . . . . . . . . . . . . . . . . . 42
	Appendix A. Compatibility with Previous Versions . . . . . . . . 42		Appendix A. Compatibility with Previous Versions . . . . . . . . 42
	A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42		A.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 42
	A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43		A.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 43
	Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44		Appendix B. Collected ABNF . . . . . . . . . . . . . . . . . . . 44
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 47		publication) . . . . . . . . . . . . . . . . . . . . 47
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 47
	C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47		C.2. Since draft-ietf-httpbis-p2-semantics-00 . . . . . . . . . 47
	C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 47		C.3. Since draft-ietf-httpbis-p2-semantics-01 . . . . . . . . . 48
	C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48		C.4. Since draft-ietf-httpbis-p2-semantics-02 . . . . . . . . . 48
	C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49		C.5. Since draft-ietf-httpbis-p2-semantics-03 . . . . . . . . . 49
	C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49		C.6. Since draft-ietf-httpbis-p2-semantics-04 . . . . . . . . . 49
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 49		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 50
			C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 50
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 54
	1. Introduction		1. Introduction
	This document defines HTTP/1.1 request and response semantics. Each		This document defines HTTP/1.1 request and response semantics. Each
	HTTP message, as defined in [Part1], is in the form of either a		HTTP message, as defined in [Part1], is in the form of either a
	request or a response. An HTTP server listens on a connection for		request or a response. An HTTP server listens on a connection for
	HTTP requests and responds to each request, in the order received on		HTTP requests and responds to each request, in the order received on
	that connection, with one or more HTTP response messages. This		that connection, with one or more HTTP response messages. This
	skipping to change at page 7, line 25		skipping to change at page 7, line 25
	RWS = <RWS, defined in [Part1], Section 1.2.2>		RWS = <RWS, defined in [Part1], Section 1.2.2>
	obs-text = <obs-text, defined in [Part1], Section 1.2.2>		obs-text = <obs-text, defined in [Part1], Section 1.2.2>
	1.2.2. ABNF Rules defined in other Parts of the Specification		1.2.2. ABNF Rules defined in other Parts of the Specification
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	absolute-URI = <absolute-URI, defined in [Part1], Section 2.1>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.1>
	fragment = <fragment, defined in [Part1], Section 2.1>		fragment = <fragment, defined in [Part1], Section 2.1>
	Host = <Host, defined in [Part1], Section 2.1>		Host = <Host, defined in [Part1], Section 2.1>
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
	partial-URI = <partial-URI, defined in [Part1], Section 2.1>		partial-URI = <partial-URI, defined in [Part1], Section 2.1>
	product = <product, defined in [Part1], Section 3.4>		product = <product, defined in [Part1], Section 3.4>
	TE = <TE, defined in [Part1], Section 8.8>		TE = <TE, defined in [Part1], Section 8.8>
	Accept = <Accept, defined in [Part3], Section 5.1>		Accept = <Accept, defined in [Part3], Section 5.1>
	Accept-Charset =		Accept-Charset =
	<Accept-Charset, defined in [Part3], Section 5.2>		<Accept-Charset, defined in [Part3], Section 5.2>
	Accept-Encoding =		Accept-Encoding =
	<Accept-Encoding, defined in [Part3], Section 5.3>		<Accept-Encoding, defined in [Part3], Section 5.3>
	Accept-Language =		Accept-Language =
	skipping to change at page 9, line 12		skipping to change at page 9, line 12
	Registrations MUST include the following fields:		Registrations MUST include the following fields:
	o Method Name (see Section 2)		o Method Name (see Section 2)
	o Safe ("yes" or "no", see Section 7.1.1)		o Safe ("yes" or "no", see Section 7.1.1)
	o Pointer to specification text		o Pointer to specification text
	Values to be added to this name space are subject to IETF review		Values to be added to this name space are subject to IETF review
	([RFC5226], Section 4.1). Any document registering new method names		([RFC5226], Section 4.1).
	should be traceable through statuses of either 'Obsoletes' or
	'Updates' to this document.
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-methods>.		<http://www.iana.org/assignments/http-methods>.
	3. Request Header Fields		3. Request Header Fields
	The request-header fields allow the client to pass additional		The request-header fields allow the client to pass additional
	information about the request, and about the client itself, to the		information about the request, and about the client itself, to the
	server. These fields act as request modifiers, with semantics		server. These fields act as request modifiers, with semantics
	equivalent to the parameters on a programming language method		equivalent to the parameters on a programming language method
	skipping to change at page 12, line 22		skipping to change at page 12, line 22
	cases, user agents SHOULD present to the user the entity returned		cases, user agents SHOULD present to the user the entity returned
	with the response, since that entity is likely to include human-		with the response, since that entity is likely to include human-
	readable information which will explain the unusual status.		readable information which will explain the unusual status.
	4.1. Status Code Registry		4.1. Status Code Registry
	The HTTP Status Code Registry defines the name space for the Status-		The HTTP Status Code Registry defines the name space for the Status-
	Code token in the Status line of an HTTP response.		Code token in the Status line of an HTTP response.
	Values to be added to this name space are subject to IETF review		Values to be added to this name space are subject to IETF review
	([RFC5226], Section 4.1). Any document registering new status codes		([RFC5226], Section 4.1).
	should be traceable through statuses of either 'Obsoletes' or
	'Updates' to this document.
	The registry itself is maintained at		The registry itself is maintained at
	<http://www.iana.org/assignments/http-status-codes>.		<http://www.iana.org/assignments/http-status-codes>.
	5. Response Header Fields		5. Response Header Fields
	The response-header fields allow the server to pass additional		The response-header fields allow the server to pass additional
	information about the response which cannot be placed in the Status-		information about the response which cannot be placed in the Status-
	Line. These header fields give information about the server and		Line. These header fields give information about the server and
	about further access to the resource identified by the request-		about further access to the resource identified by the request-
	skipping to change at page 19, line 27		skipping to change at page 19, line 27
	NOT be cached.		NOT be cached.
	7.9. CONNECT		7.9. CONNECT
	This specification reserves the method name CONNECT for use with a		This specification reserves the method name CONNECT for use with a
	proxy that can dynamically switch to being a tunnel (e.g. SSL		proxy that can dynamically switch to being a tunnel (e.g. SSL
	tunneling [RFC2817]).		tunneling [RFC2817]).
	8. Status Code Definitions		8. Status Code Definitions
	Each Status-Code is described below, including a description of which		Each Status-Code is described below, including any metainformation
	method(s) it can follow and any metainformation required in the		required in the response.
	response.
	8.1. Informational 1xx		8.1. Informational 1xx
	This class of status code indicates a provisional response,		This class of status code indicates a provisional response,
	consisting only of the Status-Line and optional headers, and is		consisting only of the Status-Line and optional headers, and is
	terminated by an empty line. There are no required headers for this		terminated by an empty line. There are no required headers for this
	class of status code. Since HTTP/1.0 did not define any 1xx status		class of status code. Since HTTP/1.0 did not define any 1xx status
	codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client		codes, servers MUST NOT send a 1xx response to an HTTP/1.0 client
	except under experimental conditions.		except under experimental conditions.
	skipping to change at page 25, line 10		skipping to change at page 25, line 10
	original request.		original request.
	A 303 response to a GET request indicates that the requested resource		A 303 response to a GET request indicates that the requested resource
	does not have a representation of its own that can be transferred by		does not have a representation of its own that can be transferred by
	the server over HTTP. The Location URI indicates a resource that is		the server over HTTP. The Location URI indicates a resource that is
	descriptive of the requested resource such that the follow-on		descriptive of the requested resource such that the follow-on
	representation may be useful without implying that it adequately		representation may be useful without implying that it adequately
	represents the previously requested resource. Note that answers to		represents the previously requested resource. Note that answers to
	the questions of what can be represented, what representations are		the questions of what can be represented, what representations are
	adequate, and what might be a useful description are outside the		adequate, and what might be a useful description are outside the
	scope of HTTP and thus entirely determined by the resource owner(s).		scope of HTTP and thus entirely determined by the URI owner(s).
	A 303 response SHOULD NOT be cached unless it is indicated as		A 303 response SHOULD NOT be cached unless it is indicated as
	cacheable by Cache-Control or Expires header fields. Except for		cacheable by Cache-Control or Expires header fields. Except for
	responses to a HEAD request, the entity of a 303 response SHOULD		responses to a HEAD request, the entity of a 303 response SHOULD
	contain a short hypertext note with a hyperlink to the Location URI.		contain a short hypertext note with a hyperlink to the Location URI.
	8.3.5. 304 Not Modified		8.3.5. 304 Not Modified
	The response to the request has not been modified since the		The response to the request has not been modified since the
	conditions indicated by the client's conditional GET request, as		conditions indicated by the client's conditional GET request, as
	skipping to change at page 35, line 10		skipping to change at page 35, line 10
	The Max-Forwards header field MAY be ignored for all other methods		The Max-Forwards header field MAY be ignored for all other methods
	defined by this specification and for any extension methods for which		defined by this specification and for any extension methods for which
	it is not explicitly referred to as part of that method definition.		it is not explicitly referred to as part of that method definition.
	9.6. Referer		9.6. Referer
	The request-header field "Referer" [sic] allows the client to		The request-header field "Referer" [sic] allows the client to
	specify, for the server's benefit, the address (URI) of the resource		specify, for the server's benefit, the address (URI) of the resource
	from which the request-target was obtained (the "referrer", although		from which the request-target was obtained (the "referrer", although
	the header field is misspelled.) The Referer request-header allows a		the header field is misspelled.).
	server to generate lists of back-links to resources for interest,
	logging, optimized caching, etc. It also allows obsolete or mistyped		The Referer header allows servers to generate lists of back-links to
	links to be traced for maintenance. The Referer field MUST NOT be		resources for interest, logging, optimized caching, etc. It also
	sent if the request-target was obtained from a source that does not		allows obsolete or mistyped links to be traced for maintenance. Some
	have its own URI, such as input from the user keyboard.		servers use Referer as a means of controlling where they allow links
			from (so-called "deep linking"), but it should be noted that
			legitimate requests are not required to contain a Referer header
			field.
			If the request-target was obtained from a source that does not have
			its own URI (e.g., input from the user keyboard), the Referer field
			MUST either be sent with the value "about:blank", or not be sent at
			all. Note that this requirement does not apply to sources with non-
			HTTP URIs (e.g., FTP).
	Referer = "Referer" ":" OWS Referer-v		Referer = "Referer" ":" OWS Referer-v
	Referer-v = absolute-URI / partial-URI		Referer-v = absolute-URI / partial-URI
	Example:		Example:
	Referer: http://www.example.org/hypertext/Overview.html		Referer: http://www.example.org/hypertext/Overview.html
	If the field value is a relative URI, it SHOULD be interpreted		If the field value is a relative URI, it SHOULD be interpreted
	relative to the request-target. The URI MUST NOT include a fragment.		relative to the request-target. The URI MUST NOT include a fragment.
	skipping to change at page 41, line 23		skipping to change at page 41, line 23
	12. Acknowledgments		12. Acknowledgments
	13. References		13. References
	13.1. Normative References		13.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-06		and Message Parsing", draft-ietf-httpbis-p1-messaging-07
	(work in progress), March 2009.		(work in progress), July 2009.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] 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 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-06		and Content Negotiation", draft-ietf-httpbis-p3-payload-07
	(work in progress), March 2009.		(work in progress), July 2009.
	[Part4] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part4] 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 4: Conditional		and J. Reschke, Ed., "HTTP/1.1, part 4: Conditional
	Requests", draft-ietf-httpbis-p4-conditional-06 (work in		Requests", draft-ietf-httpbis-p4-conditional-07 (work in
	progress), March 2009.		progress), July 2009.
	[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-06 (work		Partial Responses", draft-ietf-httpbis-p5-range-07 (work
	in progress), March 2009.		in progress), July 2009.
	[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.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		Nottingham, M., Ed., and J. Reschke, Ed., "HTTP/1.1, part
	draft-ietf-httpbis-p6-cache-06 (work in progress),		6: Caching", draft-ietf-httpbis-p6-cache-07 (work in
	March 2009.		progress), July 2009.
	[Part7] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part7] 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 7: Authentication",		and J. Reschke, Ed., "HTTP/1.1, part 7: Authentication",
	draft-ietf-httpbis-p7-auth-06 (work in progress),		draft-ietf-httpbis-p7-auth-07 (work in progress),
	March 2009.		July 2009.
	[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.
	13.2. Informative References		13.2. Informative References
	[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext		[RFC1945] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext
	skipping to change at page 44, line 22		skipping to change at page 44, line 22
	Reclassify Allow header as response header, removing the option to		Reclassify Allow header as response header, removing the option to
	specify it in a PUT request. Relax the server requirement on the		specify it in a PUT request. Relax the server requirement on the
	contents of the Allow header and remove requirement on clients to		contents of the Allow header and remove requirement on clients to
	always trust the header value. (Section 9.1)		always trust the header value. (Section 9.1)
	Correct syntax of Location header to allow fragment, as referred		Correct syntax of Location header to allow fragment, as referred
	symbol wasn't what was expected, and add some clarifications as to		symbol wasn't what was expected, and add some clarifications as to
	when it would not be appropriate. (Section 9.4)		when it would not be appropriate. (Section 9.4)
			Allow Referer value of "about:blank" as alternative to not specifying
			it. (Section 9.6)
	In the description of the Server header, the Via field was described		In the description of the Server header, the Via field was described
	as a SHOULD. The requirement was and is stated correctly in the		as a SHOULD. The requirement was and is stated correctly in the
	description of the Via header in Section 8.9 of [Part1].		description of the Via header in Section 8.9 of [Part1].
	(Section 9.8)		(Section 9.8)
	Appendix B. Collected ABNF		Appendix B. Collected ABNF
	Accept = <Accept, defined in [Part3], Section 5.1>		Accept = <Accept, defined in [Part3], Section 5.1>
	Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2>		Accept-Charset = <Accept-Charset, defined in [Part3], Section 5.2>
	Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3>		Accept-Encoding = <Accept-Encoding, defined in [Part3], Section 5.3>
	skipping to change at page 44, line 46		skipping to change at page 44, line 49
	Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]		Allow-v = [ ( "," / Method ) *( OWS "," [ OWS Method ] ) ]
	Authorization = <Authorization, defined in [Part7], Section 3.1>		Authorization = <Authorization, defined in [Part7], Section 3.1>
	ETag = <ETag, defined in [Part4], Section 6.1>		ETag = <ETag, defined in [Part4], Section 6.1>
	Expect = "Expect:" OWS Expect-v		Expect = "Expect:" OWS Expect-v
	Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )		Expect-v = *( "," OWS ) expectation *( OWS "," [ OWS expectation ] )
	From = "From:" OWS From-v		From = "From:" OWS From-v
	From-v = mailbox		From-v = mailbox
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.2.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.2>
	Host = <Host, defined in [Part1], Section 2.1>		Host = <Host, defined in [Part1], Section 2.1>
	If-Match = <If-Match, defined in [Part4], Section 6.2>		If-Match = <If-Match, defined in [Part4], Section 6.2>
	If-Modified-Since =		If-Modified-Since =
	<If-Modified-Since, defined in [Part4], Section 6.3>		<If-Modified-Since, defined in [Part4], Section 6.3>
	If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>		If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
	If-Range = <If-Range, defined in [Part5], Section 5.3>		If-Range = <If-Range, defined in [Part5], Section 5.3>
	If-Unmodified-Since =		If-Unmodified-Since =
	<If-Unmodified-Since, defined in [Part4], Section 6.5>		<If-Unmodified-Since, defined in [Part4], Section 6.5>
	Location = "Location:" OWS Location-v		Location = "Location:" OWS Location-v
	Location-v = absolute-URI [ "#" fragment ]		Location-v = absolute-URI [ "#" fragment ]
	skipping to change at page 45, line 16		skipping to change at page 45, line 17
	If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>		If-None-Match = <If-None-Match, defined in [Part4], Section 6.4>
	If-Range = <If-Range, defined in [Part5], Section 5.3>		If-Range = <If-Range, defined in [Part5], Section 5.3>
	If-Unmodified-Since =		If-Unmodified-Since =
	<If-Unmodified-Since, defined in [Part4], Section 6.5>		<If-Unmodified-Since, defined in [Part4], Section 6.5>
	Location = "Location:" OWS Location-v		Location = "Location:" OWS Location-v
	Location-v = absolute-URI [ "#" fragment ]		Location-v = absolute-URI [ "#" fragment ]
	Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v		Max-Forwards = "Max-Forwards:" OWS Max-Forwards-v
	Max-Forwards-v = 1*DIGIT		Max-Forwards-v = 1*DIGIT
	Method = %x4F.50.54.49.4F.4E.53 / %x47.45.54 / %x48.45.41.44 /		Method = %x4F.50.54.49.4F.4E.53 ; OPTIONS
	%x50.4F.54 / %x50.55.54 / %x44.45.4C.45.54.45 / %x54.52.41.43.45 /		/ %x47.45.54 ; GET
	%x43.4E.4E.45.43.54 / extension-method		/ %x48.45.41.44 ; HEAD
			/ %x50.4F.53.54 ; POST
			/ %x50.55.54 ; PUT
			/ %x44.45.4C.45.54.45 ; DELETE
			/ %x54.52.41.43.45 ; TRACE
			/ %x43.4F.4E.4E.45.43.54 ; CONNECT
			/ extension-method
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	Proxy-Authenticate =		Proxy-Authenticate =
	<Proxy-Authenticate, defined in [Part7], Section 3.2>		<Proxy-Authenticate, defined in [Part7], Section 3.2>
	Proxy-Authorization =		Proxy-Authorization =
	<Proxy-Authorization, defined in [Part7], Section 3.3>		<Proxy-Authorization, defined in [Part7], Section 3.3>
	RWS = <RWS, defined in [Part1], Section 1.2.2>		RWS = <RWS, defined in [Part1], Section 1.2.2>
	Range = <Range, defined in [Part5], Section 5.4>		Range = <Range, defined in [Part5], Section 5.4>
	skipping to change at page 50, line 14		skipping to change at page 50, line 18
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase		o <http://tools.ietf.org/wg/httpbis/trac/ticket/94>: "Reason-Phrase
	BNF"		BNF"
	Final work on ABNF conversion		Final work on ABNF conversion
	(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add appendix containing collected and expanded ABNF, reorganize		o Add appendix containing collected and expanded ABNF, reorganize
	ABNF introduction.		ABNF introduction.
			C.8. Since draft-ietf-httpbis-p2-semantics-06
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/144>: "Clarify when
			Referer is sent"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/164>: "status codes
			vs methods"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/170>: "Do not
			require "updates" relation for specs that register status codes or
			method names"
	Index		Index
	1		1
	100 Continue (status code) 20		100 Continue (status code) 20
	101 Switching Protocols (status code) 20		101 Switching Protocols (status code) 20
	2		2
	200 OK (status code) 20		200 OK (status code) 20
	201 Created (status code) 21		201 Created (status code) 21
	202 Accepted (status code) 21		202 Accepted (status code) 21
	skipping to change at page 51, line 33		skipping to change at page 52, line 4
	CONNECT method 19		CONNECT method 19
	D		D
	DELETE method 18		DELETE method 18
	E		E
	Expect header 32		Expect header 32
	F		F
	From header 33		From header 33
	G		G
	GET method 15		GET method 15
	Grammar		Grammar
	Allow 31		Allow 31
	Allow-v 31		Allow-v 31
	delta-seconds 35		delta-seconds 36
	Expect 32		Expect 32
	expect-params 32		expect-params 32
	Expect-v 32		Expect-v 32
	expectation 32		expectation 32
	expectation-extension 32		expectation-extension 32
	extension-code 11		extension-code 11
	extension-method 8		extension-method 8
	From 33		From 33
	From-v 33		From-v 33
	Location 33		Location 33
	skipping to change at page 52, line 16		skipping to change at page 52, line 34
	Reason-Phrase 11		Reason-Phrase 11
	Referer 35		Referer 35
	Referer-v 35		Referer-v 35
	request-header 9		request-header 9
	response-header 12		response-header 12
	Retry-After 35		Retry-After 35
	Retry-After-v 35		Retry-After-v 35
	Server 36		Server 36
	Server-v 36		Server-v 36
	Status-Code 11		Status-Code 11
	User-Agent 36		User-Agent 37
	User-Agent-v 36		User-Agent-v 37
	H		H
	HEAD method 16		HEAD method 16
	Headers		Headers
	Allow 31		Allow 31
	Expect 32		Expect 32
	From 33		From 33
	Location 33		Location 33
	Max-Forwards 34		Max-Forwards 34
	Referer 35		Referer 35
End of changes. 27 change blocks.
	46 lines changed or deleted		72 lines changed or added
This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/