draft-ietf-httpbis-p5-range-16.txt		draft-ietf-httpbis-p5-range-17.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
	Intended status: Standards Track Alcatel-Lucent		Intended status: Standards Track Alcatel-Lucent
	Expires: February 25, 2012 J. Mogul		Expires: May 3, 2012 J. Mogul
	HP		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
	August 24, 2011		October 31, 2011
	HTTP/1.1, part 5: Range Requests and Partial Responses		HTTP/1.1, part 5: Range Requests and Partial Responses
	draft-ietf-httpbis-p5-range-16		draft-ietf-httpbis-p5-range-17
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypertext 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 5 of the		information initiative since 1990. This document is Part 5 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.		"HTTP/1.1" and, taken together, obsoletes RFC 2616.
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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 D.17.		The changes in this draft are summarized in Appendix D.18.
	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 February 25, 2012.		This Internet-Draft will expire on May 3, 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 2, line 52		skipping to change at page 2, line 52
	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
	it for publication as an RFC or to translate it into languages other		it for publication as an RFC or to translate it into languages other
	than English.		than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 5		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 5
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 6
	1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6		1.2.1. Core Rules . . . . . . . . . . . . . . . . . . . . . . 6
	1.2.2. ABNF Rules defined in other Parts of the		1.2.2. ABNF Rules defined in other Parts of the
	Specification . . . . . . . . . . . . . . . . . . . . 6		Specification . . . . . . . . . . . . . . . . . . . . 6
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 6
	2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6		2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 7
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 7
	3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7		3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 7
	3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7		3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 8
	4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8		4. Combining Ranges . . . . . . . . . . . . . . . . . . . . . . . 8
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9
	5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9
	5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9		5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10
	5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 12
	5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13		5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 13
	5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13		5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 13
	5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15		5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 15
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
	6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15		6.1. Status Code Registration . . . . . . . . . . . . . . . . . 16
	6.2. Header Field Registration . . . . . . . . . . . . . . . . 16		6.2. Header Field Registration . . . . . . . . . . . . . . . . 16
	6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16		6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 17
	7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17		7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 17
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 17		9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
	9.2. Informative References . . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . . 18
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 18		Appendix A. Internet Media Type multipart/byteranges . . . . . . 18
	Appendix B. Compatibility with Previous Versions . . . . . . . . 20		Appendix B. Compatibility with Previous Versions . . . . . . . . 21
	B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 20		B.1. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 21
	Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 21		Appendix C. Collected ABNF . . . . . . . . . . . . . . . . . . . 22
	Appendix D. Change Log (to be removed by RFC Editor before		Appendix D. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 22		publication) . . . . . . . . . . . . . . . . . . . . 23
	D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 22		D.1. Since RFC 2616 . . . . . . . . . . . . . . . . . . . . . . 23
	D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 22		D.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 23
	D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 22		D.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 23
	D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 22		D.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 23
	D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 23		D.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 24
	D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 23		D.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 24
	D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 23		D.7. Since draft-ietf-httpbis-p5-range-05 . . . . . . . . . . . 24
	D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 23		D.8. Since draft-ietf-httpbis-p5-range-06 . . . . . . . . . . . 24
	D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 24		D.9. Since draft-ietf-httpbis-p5-range-07 . . . . . . . . . . . 25
	D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 24		D.10. Since draft-ietf-httpbis-p5-range-08 . . . . . . . . . . . 25
	D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 24		D.11. Since draft-ietf-httpbis-p5-range-09 . . . . . . . . . . . 25
	D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 24		D.12. Since draft-ietf-httpbis-p5-range-10 . . . . . . . . . . . 25
	D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 24		D.13. Since draft-ietf-httpbis-p5-range-11 . . . . . . . . . . . 25
	D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 25		D.14. Since draft-ietf-httpbis-p5-range-12 . . . . . . . . . . . 26
	D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 25		D.15. Since draft-ietf-httpbis-p5-range-13 . . . . . . . . . . . 26
	D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 25		D.16. Since draft-ietf-httpbis-p5-range-14 . . . . . . . . . . . 26
	D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 25		D.17. Since draft-ietf-httpbis-p5-range-15 . . . . . . . . . . . 26
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25		D.18. Since draft-ietf-httpbis-p5-range-16 . . . . . . . . . . . 26
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
	1. Introduction		1. Introduction
	HTTP clients often encounter interrupted data transfers as a result		HTTP clients often encounter interrupted data transfers as a result
	of cancelled requests or dropped connections. When a client has		of cancelled requests or dropped connections. When a client has
	stored a partial representation, it is desirable to request the		stored a partial representation, it is desirable to request the
	remainder of that representation in a subsequent request rather than		remainder of that representation in a subsequent request rather than
	transfer the entire representation. There are also a number of Web		transfer the entire representation. There are also a number of Web
	applications that benefit from being able to request only a subset of		applications that benefit from being able to request only a subset of
	a larger representation, such as a single page of a very large		a larger representation, such as a single page of a very large
	skipping to change at page 5, line 30		skipping to change at page 5, line 30
	that do not implement this feature can respond as if it is a normal		that do not implement this feature can respond as if it is a normal
	GET request without impacting interoperability. Partial responses		GET request without impacting interoperability. Partial responses
	are indicated by a distinct status code to not be mistaken for full		are indicated by a distinct status code to not be mistaken for full
	responses by intermediate caches that might not implement the		responses by intermediate caches that might not implement the
	feature.		feature.
	Although the HTTP range request mechanism is designed to allow for		Although the HTTP range request mechanism is designed to allow for
	extensible range types, this specification only defines requests for		extensible range types, this specification only defines requests for
	byte ranges.		byte ranges.
	1.1. Requirements		1.1. Conformance and Error Handling
	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		This document defines conformance criteria for several roles in HTTP
	of the "MUST" or "REQUIRED" level requirements for the protocols it		communication, including Senders, Recipients, Clients, Servers, User-
	implements. An implementation that satisfies all the "MUST" or		Agents, Origin Servers, Intermediaries, Proxies and Gateways. See
	"REQUIRED" level and all the "SHOULD" level requirements for its		Section 2 of [Part1] for definitions of these terms.
	protocols is said to be "unconditionally compliant"; one that
	satisfies all the "MUST" level requirements but not all the "SHOULD"		An implementation is considered conformant if it complies with all of
	level requirements for its protocols is said to be "conditionally		the requirements associated with its role(s). Note that SHOULD-level
	compliant".		requirements are relevant here, unless one of the documented
			exceptions is applicable.
			This document also uses ABNF to define valid protocol elements
			(Section 1.2). In addition to the prose requirements placed upon
			them, Senders MUST NOT generate protocol elements that are invalid.
			Unless noted otherwise, Recipients MAY take steps to recover a usable
			protocol element from an invalid construct. However, HTTP does not
			define specific error handling mechanisms, except in cases where it
			has direct impact on security. This is because different uses of the
			protocol require different error handling strategies; for example, a
			Web browser may wish to transparently recover from a response where
			the Location header field doesn't parse according to the ABNF,
			whereby in a systems control protocol using HTTP, this type of error
			recovery could lead to dangerous consequences.
	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 C shows the collected ABNF, with the list rule		rule). Appendix C 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
	(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), and VCHAR (any visible US-ASCII
	and WSP (whitespace).		character).
			Note that all rules derived from token are to be compared case-
			insensitively, like range-unit and acceptable-ranges.
	1.2.1. Core Rules		1.2.1. Core Rules
	The core rules below are defined in [Part1]:		The core rules below are defined in [Part1] and [Part2]:
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	token = <token, defined in [Part1], Section 3.2.3>		token = <token, defined in [Part1], Section 3.2.3>
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	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:
	entity-tag = <entity-tag, defined in [Part4], Section 2.3>		entity-tag = <entity-tag, defined in [Part4], Section 2.3>
	2. Range Units		2. Range Units
	HTTP/1.1 allows a client to request that only part (a range) of the		HTTP/1.1 allows a client to request that only part (a range) of the
	skipping to change at page 10, line 44		skipping to change at page 11, line 9
	value, is invalid. The recipient of an invalid byte-content-range-		value, is invalid. The recipient of an invalid byte-content-range-
	spec MUST ignore it and any content transferred along with it.		spec MUST ignore it and any content transferred along with it.
	In the case of a byte range request: A server sending a response with		In the case of a byte range request: A server sending a response with
	status code 416 (Requested range not satisfiable) SHOULD include a		status code 416 (Requested range not satisfiable) SHOULD include a
	Content-Range field with a byte-range-resp-spec of "*". The		Content-Range field with a byte-range-resp-spec of "*". The
	instance-length specifies the current length of the selected		instance-length specifies the current length of the selected
	resource. A response with status code 206 (Partial Content) MUST NOT		resource. A response with status code 206 (Partial Content) MUST NOT
	include a Content-Range field with a byte-range-resp-spec of "*".		include a Content-Range field with a byte-range-resp-spec of "*".
			The "Content-Range" header field has no meaning for status codes that
			do not explicitly describe its semantic. Currently, only status
			codes 206 (Partial Content) and 416 (Requested range not satisfiable)
			describe the meaning of this header field.
	Examples of byte-content-range-spec values, assuming that the		Examples of byte-content-range-spec values, assuming that the
	representation contains a total of 1234 bytes:		representation contains a total of 1234 bytes:
	o The first 500 bytes:		o The first 500 bytes:
	bytes 0-499/1234		bytes 0-499/1234
	o The second 500 bytes:		o The second 500 bytes:
	bytes 500-999/1234		bytes 500-999/1234
	skipping to change at page 17, line 15		skipping to change at page 17, line 31
	some suggestions for reducing security risks.		some suggestions for reducing security risks.
	7.1. Overlapping Ranges		7.1. Overlapping Ranges
	Range requests containing overlapping ranges may lead to the		Range requests containing overlapping ranges may lead to the
	situation where a server is sending far more data than the size of		situation where a server is sending far more data than the size of
	the complete resource representation.		the complete resource representation.
	8. Acknowledgments		8. Acknowledgments
	See Section 12 of [Part1].		See Section 11 of [Part1].
	9. References		9. References
	9.1. Normative References		9.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-16		and Message Parsing", draft-ietf-httpbis-p1-messaging-17
	(work in progress), August 2011.		(work in progress), October 2011.
			[Part2] 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 2: Message
			Semantics", draft-ietf-httpbis-p2-semantics-17 (work in
			progress), October 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-16 (work in		Requests", draft-ietf-httpbis-p4-conditional-17 (work in
	progress), August 2011.		progress), October 2011.
	[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail		[RFC2046] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
	Extensions (MIME) Part Two: Media Types", RFC 2046,		Extensions (MIME) Part Two: Media Types", RFC 2046,
	November 1996.		November 1996.
	[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.
	skipping to change at page 21, line 11		skipping to change at page 22, line 11
	Clarify that multipart/byteranges can consist of a single part.		Clarify that multipart/byteranges can consist of a single part.
	(Appendix A)		(Appendix A)
	Appendix C. Collected ABNF		Appendix C. Collected ABNF
	Accept-Ranges = acceptable-ranges		Accept-Ranges = acceptable-ranges
	Content-Range = byte-content-range-spec / other-content-range-spec		Content-Range = byte-content-range-spec / other-content-range-spec
	HTTP-date = <HTTP-date, defined in [Part1], Section 6.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8>
	If-Range = entity-tag / HTTP-date		If-Range = entity-tag / HTTP-date
	OWS = <OWS, defined in [Part1], Section 1.2.2>		OWS = <OWS, defined in [Part1], Section 1.2.2>
	Range = byte-ranges-specifier / other-ranges-specifier		Range = byte-ranges-specifier / other-ranges-specifier
	acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS		acceptable-ranges = ( *( "," OWS ) range-unit *( OWS "," [ OWS
	range-unit ] ) ) / "none"		range-unit ] ) ) / "none"
	skipping to change at page 25, line 30		skipping to change at page 26, line 30
	None.		None.
	D.17. Since draft-ietf-httpbis-p5-range-15		D.17. Since draft-ietf-httpbis-p5-range-15
	Closed issues:		Closed issues:
	o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security		o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
	consideration: range flooding"		consideration: range flooding"
			D.18. Since draft-ietf-httpbis-p5-range-16
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/186>: "Document
			HTTP's error-handling philosophy"
			o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/301>: "Content-
			Range on responses other than 206"
			o <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/319>: "case
			sensitivity of ranges in p5"
	Index		Index
	2		2
	206 Partial Content (status code) 7		206 Partial Content (status code) 7
	4		4
	416 Requested Range Not Satisfiable (status code) 7		416 Requested Range Not Satisfiable (status code) 8
	A		A
	Accept-Ranges header field 9		Accept-Ranges header field 9
	C		C
	Content-Range header field 9		Content-Range header field 10
	G		G
	Grammar		Grammar
	Accept-Ranges 9		Accept-Ranges 9
	acceptable-ranges 9		acceptable-ranges 9
	byte-content-range-spec 10		byte-content-range-spec 10
	byte-range-resp-spec 10		byte-range-resp-spec 10
	byte-range-set 13		byte-range-set 13
	byte-range-spec 13		byte-range-spec 13
	byte-ranges-specifier 13		byte-ranges-specifier 13
	skipping to change at page 26, line 20		skipping to change at page 27, line 33
	other-range-unit 6		other-range-unit 6
	Range 15		Range 15
	range-unit 6		range-unit 6
	ranges-specifier 13		ranges-specifier 13
	suffix-byte-range-spec 14		suffix-byte-range-spec 14
	suffix-length 14		suffix-length 14
	H		H
	Header Fields		Header Fields
	Accept-Ranges 9		Accept-Ranges 9
	Content-Range 9		Content-Range 10
	If-Range 12		If-Range 12
	Range 13		Range 13
	I		I
	If-Range header field 12		If-Range header field 12
	M		M
	Media Type		Media Type
	multipart/byteranges 18		multipart/byteranges 18
	multipart/x-byteranges 20		multipart/x-byteranges 21
	multipart/byteranges Media Type 18		multipart/byteranges Media Type 18
	multipart/x-byteranges Media Type 20		multipart/x-byteranges Media Type 21
	R		R
	Range header field 13		Range header field 13
	S		S
	Status Codes		Status Codes
	206 Partial Content 7		206 Partial Content 7
	416 Requested Range Not Satisfiable 7		416 Requested Range Not Satisfiable 8
	Authors' Addresses		Authors' Addresses
	Roy T. Fielding (editor)		Roy T. Fielding (editor)
	Adobe Systems Incorporated		Adobe Systems Incorporated
	345 Park Ave		345 Park Ave
	San Jose, CA 95110		San Jose, CA 95110
	USA		USA
	EMail: fielding@gbiv.com		EMail: fielding@gbiv.com
End of changes. 32 change blocks.
	62 lines changed or deleted		104 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/