draft-ietf-httpbis-p2-semantics-15.txt		draft-ietf-httpbis-p2-semantics-16.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Updates: 2817 (if approved) Alcatel-Lucent		Updates: 2817 (if approved) Alcatel-Lucent
	Intended status: Standards Track J. Mogul		Intended status: Standards Track J. Mogul
	Expires: January 12, 2012 HP		Expires: February 25, 2012 HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe		Adobe
	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
	July 11, 2011		August 24, 2011
	HTTP/1.1, part 2: Message Semantics		HTTP/1.1, part 2: Message Semantics
	draft-ietf-httpbis-p2-semantics-15		draft-ietf-httpbis-p2-semantics-16
	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, hypertext 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 2 of the		information initiative since 1990. This document is Part 2 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 2 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	the semantics of HTTP messages as expressed by request methods,
	request header fields, response status codes, and response header		Part 2 defines the semantics of HTTP messages as expressed by request
	fields.		methods, request header fields, response status codes, and response
			header 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), which is archived at		group mailing list (ietf-http-wg@w3.org), which is archived at
	<http://lists.w3.org/Archives/Public/ietf-http-wg/>.		<http://lists.w3.org/Archives/Public/ietf-http-wg/>.
	The current issues list is at		The current issues list is at
	<http://tools.ietf.org/wg/httpbis/trac/report/3> and related		<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.16.		The changes in this draft are summarized in Appendix C.17.
	Status of This Memo		Status of This Memo
	This Internet-Draft is submitted 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). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		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."
	This Internet-Draft will expire on January 12, 2012.		This Internet-Draft will expire on February 25, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2011 IETF Trust and the persons identified as the		Copyright (c) 2011 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 5, line 29		skipping to change at page 5, line 31
	C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54		C.7. Since draft-ietf-httpbis-p2-semantics-05 . . . . . . . . . 54
	C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54		C.8. Since draft-ietf-httpbis-p2-semantics-06 . . . . . . . . . 54
	C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54		C.9. Since draft-ietf-httpbis-p2-semantics-07 . . . . . . . . . 54
	C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55		C.10. Since draft-ietf-httpbis-p2-semantics-08 . . . . . . . . . 55
	C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55		C.11. Since draft-ietf-httpbis-p2-semantics-09 . . . . . . . . . 55
	C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55		C.12. Since draft-ietf-httpbis-p2-semantics-10 . . . . . . . . . 55
	C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56		C.13. Since draft-ietf-httpbis-p2-semantics-11 . . . . . . . . . 56
	C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56		C.14. Since draft-ietf-httpbis-p2-semantics-12 . . . . . . . . . 56
	C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58		C.15. Since draft-ietf-httpbis-p2-semantics-13 . . . . . . . . . 58
	C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 58		C.16. Since draft-ietf-httpbis-p2-semantics-14 . . . . . . . . . 58
			C.17. Since draft-ietf-httpbis-p2-semantics-15 . . . . . . . . . 58
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
	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
	document defines the commonly agreed upon semantics of the HTTP		document defines the commonly agreed upon semantics of the HTTP
	skipping to change at page 7, line 9		skipping to change at page 7, line 9
	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
	(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),		(CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double quote),
	HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit		HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any 8-bit
	sequence of data), SP (space), VCHAR (any visible USASCII character),		sequence of data), SP (space), VCHAR (any visible USASCII character),
	and WSP (whitespace).		and WSP (whitespace).
	1.2.1. Core Rules		1.2.1. Core Rules
	The core rules below are defined in Section 1.2.2 of [Part1]:		The core rules below are defined in [Part1]:
	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>
	token = <token, defined in [Part1], Section 1.2.2>
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	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>
			quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
			token = <token, defined in [Part1], Section 3.2.3>
	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.7>		absolute-URI = <absolute-URI, defined in [Part1], Section 2.7>
	comment = <comment, defined in [Part1], Section 3.2>		comment = <comment, defined in [Part1], Section 3.2>
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	product = <product, defined in [Part1], Section 6.3>		product = <product, defined in [Part1], Section 6.3>
	skipping to change at page 13, line 21		skipping to change at page 13, line 21
	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 target resource (Section 4.3 of [Part1]).		about further access to the target resource (Section 4.3 of [Part1]).
	+--------------------+------------------------+		+--------------------+------------------------+
	| Header Field Name | Defined in... |		| Header Field Name | Defined in... |
	+--------------------+------------------------+		+--------------------+------------------------+
	| Accept-Ranges | Section 5.1 of [Part5] |		| Accept-Ranges | Section 5.1 of [Part5] |
	| Age | Section 3.1 of [Part6] |		| Age | Section 3.1 of [Part6] |
	| Allow | Section 9.1 |		| Allow | Section 9.1 |
	| ETag | Section 2.2 of [Part4] |		| ETag | Section 2.3 of [Part4] |
	| Location | Section 9.4 |		| Location | Section 9.4 |
	| Proxy-Authenticate | Section 4.2 of [Part7] |		| Proxy-Authenticate | Section 4.2 of [Part7] |
	| Retry-After | Section 9.7 |		| Retry-After | Section 9.7 |
	| Server | Section 9.8 |		| Server | Section 9.8 |
	| Vary | Section 3.5 of [Part6] |		| Vary | Section 3.5 of [Part6] |
	| WWW-Authenticate | Section 4.4 of [Part7] |		| WWW-Authenticate | Section 4.4 of [Part7] |
	+--------------------+------------------------+		+--------------------+------------------------+
	6. Representation		6. Representation
	skipping to change at page 14, line 18		skipping to change at page 14, line 18
	always the case. To determine the URI of the resource a response is		always the case. To determine the URI of the resource a response is
	associated with, the following rules are used (with the first		associated with, the following rules are used (with the first
	applicable one being selected):		applicable one being selected):
	1. If the response status code is 200 or 203 and the request method		1. If the response status code is 200 or 203 and the request method
	was GET, the response payload is a representation of the target		was GET, the response payload is a representation of the target
	resource.		resource.
	2. If the response status code is 204, 206, or 304 and the request		2. If the response status code is 204, 206, or 304 and the request
	method was GET or HEAD, the response payload is a partial		method was GET or HEAD, the response payload is a partial
	representation of the target resource (see Section 2.8 of		representation of the target resource.
	[Part6]).
	3. If the response has a Content-Location header field, and that URI		3. If the response has a Content-Location header field, and that URI
	is the same as the effective request URI, the response payload is		is the same as the effective request URI, the response payload is
	a representation of the target resource.		a representation of the target resource.
	4. If the response has a Content-Location header field, and that URI		4. If the response has a Content-Location header field, and that URI
	is not the same as the effective request URI, then the response		is not the same as the effective request URI, then the response
	asserts that its payload is a representation of the resource		asserts that its payload is a representation of the resource
	identified by the Content-Location URI. However, such an		identified by the Content-Location URI. However, such an
	assertion cannot be trusted unless it can be verified by other		assertion cannot be trusted unless it can be verified by other
	skipping to change at page 17, line 35		skipping to change at page 17, line 34
	can be used for obtaining metadata about the representation implied		can be used for obtaining metadata about the representation implied
	by the request without transferring the representation body. This		by the request without transferring the representation body. This
	method is often used for testing hypertext links for validity,		method is often used for testing hypertext links for validity,
	accessibility, and recent modification.		accessibility, and recent modification.
	The response to a HEAD request is cacheable and MAY be used to		The response to a HEAD request is cacheable and MAY be used to
	satisfy a subsequent HEAD request; see [Part6]. It also MAY be used		satisfy a subsequent HEAD request; see [Part6]. It also MAY be used
	to update a previously cached representation from that resource; if		to update a previously cached representation from that resource; if
	the new field values indicate that the cached representation differs		the new field values indicate that the cached representation differs
	from the current representation (as would be indicated by a change in		from the current representation (as would be indicated by a change in
	Content-Length, Content-MD5, ETag or Last-Modified), then the cache		Content-Length, ETag or Last-Modified), then the cache MUST treat the
	MUST treat the cache entry as stale.		cache entry as stale.
	Bodies on HEAD requests have no defined semantics. Note that sending		Bodies on HEAD requests have no defined semantics. Note that sending
	a body on a HEAD request might cause some existing implementations to		a body on a HEAD request might cause some existing implementations to
	reject the request.		reject the request.
	7.5. POST		7.5. POST
	The POST method requests that the origin server accept the		The POST method requests that the origin server accept the
	representation enclosed in the request as data to be processed by the		representation enclosed in the request as data to be processed by the
	target resource. POST is designed to allow a uniform method to cover		target resource. POST is designed to allow a uniform method to cover
	skipping to change at page 25, line 7		skipping to change at page 25, line 5
	response SHOULD include a payload containing a list of resource		response SHOULD include a payload containing a list of resource
	characteristics and location(s) from which the user or user agent can		characteristics and location(s) from which the user or user agent can
	choose the one most appropriate. The payload format is specified by		choose the one most appropriate. The payload format is specified by
	the media type given in the Content-Type header field. The origin		the media type given in the Content-Type header field. The origin
	server MUST create the resource before returning the 201 status code.		server MUST create the resource before returning the 201 status code.
	If the action cannot be carried out immediately, the server SHOULD		If the action cannot be carried out immediately, the server SHOULD
	respond with 202 (Accepted) response instead.		respond with 202 (Accepted) response instead.
	A 201 response MAY contain an ETag response header field indicating		A 201 response MAY contain an ETag response header field indicating
	the current value of the entity-tag for the representation of the		the current value of the entity-tag for the representation of the
	resource just created (see Section 2.2 of [Part4]).		resource just created (see Section 2.3 of [Part4]).
	8.2.3. 202 Accepted		8.2.3. 202 Accepted
	The request has been accepted for processing, but the processing has		The request has been accepted for processing, but the processing has
	not been completed. The request might or might not eventually be		not been completed. The request might or might not eventually be
	acted upon, as it might be disallowed when processing actually takes		acted upon, as it might be disallowed when processing actually takes
	place. There is no facility for re-sending a status code from an		place. There is no facility for re-sending a status code from an
	asynchronous operation such as this.		asynchronous operation such as this.
	The 202 response is intentionally non-committal. Its purpose is to		The 202 response is intentionally non-committal. Its purpose is to
	skipping to change at page 30, line 35		skipping to change at page 30, line 35
	SHOULD be careful to ensure that the client acknowledges receipt of		SHOULD be careful to ensure that the client acknowledges receipt of
	the packet(s) containing the response, before the server closes the		the packet(s) containing the response, before the server closes the
	input connection. If the client continues sending data to the server		input connection. If the client continues sending data to the server
	after the close, the server's TCP stack will send a reset packet to		after the close, the server's TCP stack will send a reset packet to
	the client, which might erase the client's unacknowledged input		the client, which might erase the client's unacknowledged input
	buffers before they can be read and interpreted by the HTTP		buffers before they can be read and interpreted by the HTTP
	application.		application.
	8.4.1. 400 Bad Request		8.4.1. 400 Bad Request
	The request could not be understood by the server due to malformed		The server cannot or will not process the request, due to a client
	syntax. The client SHOULD NOT repeat the request without		error (e.g., malformed syntax).
	modifications.
	8.4.2. 401 Unauthorized		8.4.2. 401 Unauthorized
	The request requires user authentication (see Section 3.1 of		The request requires user authentication (see Section 3.1 of
	[Part7]).		[Part7]).
	8.4.3. 402 Payment Required		8.4.3. 402 Payment Required
	This code is reserved for future use.		This code is reserved for future use.
	skipping to change at page 31, line 35		skipping to change at page 31, line 34
	8.4.6. 405 Method Not Allowed		8.4.6. 405 Method Not Allowed
	The method specified in the Request-Line is not allowed for the		The method specified in the Request-Line is not allowed for the
	target resource. The response MUST include an Allow header field		target resource. The response MUST include an Allow header field
	containing a list of valid methods for the requested resource.		containing a list of valid methods for the requested resource.
	8.4.7. 406 Not Acceptable		8.4.7. 406 Not Acceptable
	The resource identified by the request is only capable of generating		The resource identified by the request is only capable of generating
	response representations which have content characteristics not		response representations which have content characteristics not
	acceptable according to the accept header fields sent in the request.		acceptable according to the Accept and Accept-* header fields sent in
			the request (see Section 6 of [Part3]).
	Unless it was a HEAD request, the response SHOULD include a		Unless it was a HEAD request, the response SHOULD include a
	representation containing a list of available representation		representation containing a list of available representation
	characteristics and location(s) from which the user or user agent can		characteristics and location(s) from which the user or user agent can
	choose the one most appropriate. The data format is specified by the		choose the one most appropriate. The data format is specified by the
	media type given in the Content-Type header field. Depending upon		media type given in the Content-Type header field. Depending upon
	the format and the capabilities of the user agent, selection of the		the format and the capabilities of the user agent, selection of the
	most appropriate choice MAY be performed automatically. However,		most appropriate choice MAY be performed automatically. However,
	this specification does not define any standard for such automatic		this specification does not define any standard for such automatic
	selection.		selection.
	skipping to change at page 46, line 27		skipping to change at page 46, line 27
	11.4. Security Considerations for CONNECT		11.4. Security Considerations for CONNECT
	Since tunneled data is opaque to the proxy, there are additional		Since tunneled data is opaque to the proxy, there are additional
	risks to tunneling to other well-known or reserved ports. A HTTP		risks to tunneling to other well-known or reserved ports. A HTTP
	client CONNECTing to port 25 could relay spam via SMTP, for example.		client CONNECTing to port 25 could relay spam via SMTP, for example.
	As such, proxies SHOULD restrict CONNECT access to a small number of		As such, proxies SHOULD restrict CONNECT access to a small number of
	known ports.		known ports.
	12. Acknowledgments		12. Acknowledgments
			See Section 12 of [Part1].
	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-15		and Message Parsing", draft-ietf-httpbis-p1-messaging-16
	(work in progress), July 2011.		(work in progress), August 2011.
	[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-15		and Content Negotiation", draft-ietf-httpbis-p3-payload-16
	(work in progress), July 2011.		(work in progress), August 2011.
	[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-15 (work in		Requests", draft-ietf-httpbis-p4-conditional-16 (work in
	progress), July 2011.		progress), August 2011.
	[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-15 (work		Partial Responses", draft-ietf-httpbis-p5-range-16 (work
	in progress), July 2011.		in progress), August 2011.
	[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-15 (work in		6: Caching", draft-ietf-httpbis-p6-cache-16 (work in
	progress), July 2011.		progress), August 2011.
	[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-15 (work in progress),		draft-ietf-httpbis-p7-auth-16 (work in progress),
	July 2011.		August 2011.
	[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.
	[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform		[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
	Resource Identifier (URI): Generic Syntax", STD 66,		Resource Identifier (URI): Generic Syntax", STD 66,
	RFC 3986, January 2005.		RFC 3986, January 2005.
	[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.
	skipping to change at page 50, line 48		skipping to change at page 50, line 48
	expectation-extension = token [ "=" ( token / quoted-string )		expectation-extension = token [ "=" ( token / quoted-string )
	*expect-params ]		*expect-params ]
	mailbox = <mailbox, defined in [RFC5322], Section 3.4>		mailbox = <mailbox, defined in [RFC5322], Section 3.4>
	obs-text = <obs-text, defined in [Part1], Section 1.2.2>		obs-text = <obs-text, defined in [Part1], Section 1.2.2>
	partial-URI = <partial-URI, defined in [Part1], Section 2.7>		partial-URI = <partial-URI, defined in [Part1], Section 2.7>
	product = <product, defined in [Part1], Section 6.3>		product = <product, defined in [Part1], Section 6.3>
	quoted-string = <quoted-string, defined in [Part1], Section 1.2.2>		quoted-string = <quoted-string, defined in [Part1], Section 3.2.3>
	token = <token, defined in [Part1], Section 1.2.2>		token = <token, defined in [Part1], Section 3.2.3>
	ABNF diagnostics:		ABNF diagnostics:
	; Allow defined but not used		; Allow defined but not used
	; Expect defined but not used		; Expect defined but not used
	; From defined but not used		; From defined but not used
	; Location defined but not used		; Location defined but not used
	; Max-Forwards defined but not used		; Max-Forwards defined but not used
	; Reason-Phrase defined but not used		; Reason-Phrase defined but not used
	; Referer defined but not used		; Referer defined but not used
	; Retry-After defined but not used		; Retry-After defined but not used
	skipping to change at page 58, line 31		skipping to change at page 58, line 31
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403		o <http://tools.ietf.org/wg/httpbis/trac/ticket/294>: "clarify 403
	forbidden"		forbidden"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203		o <http://tools.ietf.org/wg/httpbis/trac/ticket/296>: "Clarify 203
	Non-Authoritative Information"		Non-Authoritative Information"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update		o <http://tools.ietf.org/wg/httpbis/trac/ticket/298>: "update
	default reason phrase for 413"		default reason phrase for 413"
			C.17. Since draft-ietf-httpbis-p2-semantics-15
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/285>: "Strength of
			requirements on Accept re: 406"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/303>: "400 response
			isn't generic"
	Index		Index
	1		1
	100 Continue (status code) 23		100 Continue (status code) 23
	101 Switching Protocols (status code) 23		101 Switching Protocols (status code) 23
	2		2
	200 OK (status code) 24		200 OK (status code) 24
	201 Created (status code) 24		201 Created (status code) 24
	202 Accepted (status code) 25		202 Accepted (status code) 25
End of changes. 27 change blocks.
	37 lines changed or deleted		50 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/