draft-ietf-httpbis-p5-range-20.txt		draft-ietf-httpbis-p5-range-21.txt
	HTTPbis Working Group R. Fielding, Ed.		HTTPbis Working Group R. Fielding, Ed.
	Internet-Draft Adobe		Internet-Draft Adobe
	Obsoletes: 2616 (if approved) Y. Lafon, Ed.		Obsoletes: 2616 (if approved) Y. Lafon, Ed.
	Intended status: Standards Track W3C		Intended status: Standards Track W3C
	Expires: January 17, 2013 J. Reschke, Ed.		Expires: April 7, 2013 J. Reschke, Ed.
	greenbytes		greenbytes
	July 16, 2012		October 4, 2012
	HTTP/1.1, part 5: Range Requests		Hypertext Transfer Protocol (HTTP/1.1): Range Requests
	draft-ietf-httpbis-p5-range-20		draft-ietf-httpbis-p5-range-21
	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. This document defines range requests and the rules for		systems. This document defines range requests and the rules for
	constructing and combining responses to those requests.		constructing and combining responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft takes place on the HTTPBIS working group		Discussion of this draft takes place on the HTTPBIS working group
	mailing list (ietf-http-wg@w3.org), which is archived at		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 E.1.		The changes in this draft are summarized in Appendix E.2.
	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 17, 2013.		This Internet-Draft will expire on April 7, 2013.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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 3, line 9		skipping to change at page 3, line 9
	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 . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 5		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 6		2.1. Range Specifier Registry . . . . . . . . . . . . . . . . . 5
	3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 6		3. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
	3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 6		3.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5
	3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 7		3.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6
	4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7		4. Responses to a Range Request . . . . . . . . . . . . . . . . . 7
	4.1. Response to a Single and Multiple Ranges Request . . . . . 7		4.1. Response to a Single and Multiple Ranges Request . . . . . 7
	4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 8		4.2. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 7
	5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 9		5. Header Field Definitions . . . . . . . . . . . . . . . . . . . 8
	5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 9		5.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 8
	5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 10		5.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 9
	5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 11		5.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
	5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 12		5.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 11
	5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 12		5.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
	5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 14		5.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 13
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
	6.1. Status Code Registration . . . . . . . . . . . . . . . . . 15		6.1. Status Code Registration . . . . . . . . . . . . . . . . . 14
	6.2. Header Field Registration . . . . . . . . . . . . . . . . 15		6.2. Header Field Registration . . . . . . . . . . . . . . . . 15
	6.3. Range Specifier Registration . . . . . . . . . . . . . . . 16		6.3. Range Specifier Registration . . . . . . . . . . . . . . . 15
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 16		7. Security Considerations . . . . . . . . . . . . . . . . . . . 15
	7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16		7.1. Overlapping Ranges . . . . . . . . . . . . . . . . . . . . 16
	8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16		8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
	9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	9.1. Normative References . . . . . . . . . . . . . . . . . . . 16		9.1. Normative References . . . . . . . . . . . . . . . . . . . 16
	9.2. Informative References . . . . . . . . . . . . . . . . . . 17		9.2. Informative References . . . . . . . . . . . . . . . . . . 16
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 18		Appendix A. Internet Media Type multipart/byteranges . . . . . . 17
	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20		Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 19
	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 20		Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 19
	Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21		Appendix D. Collected ABNF . . . . . . . . . . . . . . . . . . . 21
	Appendix E. Change Log (to be removed by RFC Editor before		Appendix E. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 22		publication) . . . . . . . . . . . . . . . . . . . . 22
	E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22		E.1. Since draft-ietf-httpbis-p5-range-19 . . . . . . . . . . . 22
			E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 22
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
	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 canceled requests or dropped connections. When a client has		of canceled 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
	skipping to change at page 4, line 36		skipping to change at page 4, line 36
	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. Conformance and Error Handling		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].
	This specification targets conformance criteria according to the role		Conformance criteria and considerations regarding error handling are
	of a participant in HTTP communication. Hence, HTTP requirements are		defined in Section 2.5 of [Part1].
	placed on senders, recipients, clients, servers, user agents,
	intermediaries, origin servers, proxies, gateways, or caches,
	depending on what behavior is being constrained by the requirement.
	See Section 2 of [Part1] for definitions of these terms.
	The verb "generate" is used instead of "send" where a requirement
	differentiates between creating a protocol element and merely
	forwarding a received element downstream.
	An implementation is considered conformant if it complies with all of
	the requirements associated with the roles it partakes in HTTP. Note
	that SHOULD-level 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 do not match
	the grammar defined by the ABNF rules for those protocol elements
	that are applicable to the sender's role. If a received protocol
	element is processed, the recipient MUST be able to parse any value
	that would match the ABNF rules for that protocol element, excluding
	only those rules not applicable to the recipient's role.
	Unless noted otherwise, a recipient MAY attempt to recover a usable
	protocol element from an invalid construct. HTTP does not define
	specific error handling mechanisms except when they have a direct
	impact on security, since different applications of the protocol
	require different error handling strategies. For example, a Web
	browser might wish to transparently recover from a response where the
	Location header field doesn't parse according to the ABNF, whereas a
	systems control client might consider any form of error recovery to
	be dangerous.
	1.2. Syntax Notation		1.2. Syntax Notation
	This specification uses the Augmented Backus-Naur Form (ABNF)		This specification uses the Augmented Backus-Naur Form (ABNF)
	notation of [RFC5234] with the list rule extension defined in Section		notation of [RFC5234] with the list rule extension defined in Section
	1.2 of [Part1]. Appendix C describes rules imported from other		1.2 of [Part1]. Appendix C describes rules imported from other
	documents. Appendix D shows the collected ABNF with the list rule		documents. Appendix D shows the collected ABNF with the list rule
	expanded.		expanded.
	2. Range Units		2. Range Units
	skipping to change at page 12, line 37		skipping to change at page 12, line 4
	representation using a 200 (OK) response.		representation using a 200 (OK) response.
	5.4. Range		5.4. Range
	5.4.1. Byte Ranges		5.4.1. Byte Ranges
	Since all HTTP representations are transferred as sequences of bytes,		Since all HTTP representations are transferred as sequences of bytes,
	the concept of a byte range is meaningful for any HTTP		the concept of a byte range is meaningful for any HTTP
	representation. (However, not all clients and servers need to		representation. (However, not all clients and servers need to
	support byte-range operations.)		support byte-range operations.)
	Byte range specifications in HTTP apply to the sequence of bytes in		Byte range specifications in HTTP apply to the sequence of bytes in
	the representation body (not necessarily the same as the message		the representation data (not necessarily the same as the message
	body).		body).
	A byte range operation MAY specify a single range of bytes, or a set		A byte range operation MAY specify a single range of bytes, or a set
	of ranges within a single representation.		of ranges within a single representation.
	byte-ranges-specifier = bytes-unit "=" byte-range-set		byte-ranges-specifier = bytes-unit "=" byte-range-set
	byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )		byte-range-set = 1#( byte-range-spec / suffix-byte-range-spec )
	byte-range-spec = first-byte-pos "-" [ last-byte-pos ]		byte-range-spec = first-byte-pos "-" [ last-byte-pos ]
	first-byte-pos = 1*DIGIT		first-byte-pos = 1*DIGIT
	last-byte-pos = 1*DIGIT		last-byte-pos = 1*DIGIT
	skipping to change at page 13, line 16		skipping to change at page 12, line 30
	positions specified are inclusive. Byte offsets start at zero.		positions specified are inclusive. Byte offsets start at zero.
	If the last-byte-pos value is present, it MUST be greater than or		If the last-byte-pos value is present, it MUST be greater than or
	equal to the first-byte-pos in that byte-range-spec, or the byte-		equal to the first-byte-pos in that byte-range-spec, or the byte-
	range-spec is syntactically invalid. The recipient of a byte-range-		range-spec is syntactically invalid. The recipient of a byte-range-
	set that includes one or more syntactically invalid byte-range-spec		set that includes one or more syntactically invalid byte-range-spec
	values MUST ignore the header field that includes that byte-range-		values MUST ignore the header field that includes that byte-range-
	set.		set.
	If the last-byte-pos value is absent, or if the value is greater than		If the last-byte-pos value is absent, or if the value is greater than
	or equal to the current length of the representation body, last-byte-		or equal to the current length of the representation data, last-byte-
	pos is taken to be equal to one less than the current length of the		pos is taken to be equal to one less than the current length of the
	representation in bytes.		representation in bytes.
	By its choice of last-byte-pos, a client can limit the number of		By its choice of last-byte-pos, a client can limit the number of
	bytes retrieved without knowing the size of the representation.		bytes retrieved without knowing the size of the representation.
	suffix-byte-range-spec = "-" suffix-length		suffix-byte-range-spec = "-" suffix-length
	suffix-length = 1*DIGIT		suffix-length = 1*DIGIT
	A suffix-byte-range-spec is used to specify the suffix of the		A suffix-byte-range-spec is used to specify the suffix of the
	representation body, of a length given by the suffix-length value.		representation data, of a length given by the suffix-length value.
	(That is, this form specifies the last N bytes of a representation.)		(That is, this form specifies the last N bytes of a representation.)
	If the representation is shorter than the specified suffix-length,		If the representation is shorter than the specified suffix-length,
	the entire representation is used.		the entire representation is used.
	If a syntactically valid byte-range-set includes at least one byte-		If a syntactically valid byte-range-set includes at least one byte-
	range-spec whose first-byte-pos is less than the current length of		range-spec whose first-byte-pos is less than the current length of
	the representation, or at least one suffix-byte-range-spec with a		the representation, or at least one suffix-byte-range-spec with a
	non-zero suffix-length, then the byte-range-set is satisfiable.		non-zero suffix-length, then the byte-range-set is satisfiable.
	Otherwise, the byte-range-set is unsatisfiable. If the byte-range-		Otherwise, the byte-range-set is unsatisfiable. If the byte-range-
	set is unsatisfiable, the server SHOULD return a response with a 416		set is unsatisfiable, the server SHOULD return a response with a 416
	skipping to change at page 14, line 35		skipping to change at page 13, line 47
	o Several legal but not canonical specifications of the second 500		o Several legal but not canonical specifications of the second 500
	bytes (byte offsets 500-999, inclusive):		bytes (byte offsets 500-999, inclusive):
	bytes=500-600,601-999		bytes=500-600,601-999
	bytes=500-700,601-999		bytes=500-700,601-999
	5.4.2. Range Retrieval Requests		5.4.2. Range Retrieval Requests
	The "Range" header field defines the GET method (conditional or not)		The "Range" header field defines the GET method (conditional or not)
	to request one or more sub-ranges of the response representation		to request one or more sub-ranges of the response representation
	body, instead of the entire representation body.		data, instead of the entire representation data.
	Range = byte-ranges-specifier / other-ranges-specifier		Range = byte-ranges-specifier / other-ranges-specifier
	other-ranges-specifier = other-range-unit "=" other-range-set		other-ranges-specifier = other-range-unit "=" other-range-set
	other-range-set = 1*CHAR		other-range-set = 1*CHAR
	A server MAY ignore the Range header field. However, origin servers		A server MAY ignore the Range header field. However, origin servers
	and intermediate caches ought to support byte ranges when possible,		and intermediate caches ought to support byte ranges when possible,
	since Range supports efficient recovery from partially failed		since Range supports efficient recovery from partially failed
	transfers, and supports efficient partial retrieval of large		transfers, and supports efficient partial retrieval of large
	representations.		representations.
	skipping to change at page 16, line 50		skipping to change at page 16, line 19
	the complete resource representation.		the complete resource representation.
	8. Acknowledgments		8. Acknowledgments
	See Section 9 of [Part1].		See Section 9 of [Part1].
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[Part1] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 1: Message Routing and Syntax"",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-20 (work in progress),		draft-ietf-httpbis-p1-messaging-21 (work in progress),
	July 2012.		October 2012.
	[Part2] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 2: Semantics and Payloads",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-20 (work in progress),		draft-ietf-httpbis-p2-semantics-21 (work in progress),
	July 2012.		October 2012.
	[Part4] Fielding, R., Ed., Lafon, Y., Ed., and J. Reschke, Ed.,		[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	"HTTP/1.1, part 4: Conditional Requests",		Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-20 (work in progress),		draft-ietf-httpbis-p4-conditional-21 (work in progress),
	July 2012.		October 2012.
	[Part6] Fielding, R., Ed., Lafon, Y., Ed., Nottingham, M., Ed.,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-20 (work in progress),		draft-ietf-httpbis-p6-cache-21 (work in progress),
	July 2012.		October 2012.
	[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 20, line 24		skipping to change at page 19, line 45
	x-byteranges, which is almost, but not quite compatible with the		x-byteranges, which is almost, but not quite compatible with the
	version documented in HTTP/1.1.		version documented in HTTP/1.1.
	Appendix B. Changes from RFC 2616		Appendix B. Changes from RFC 2616
	Introduce Range Specifier Registry. (Section 2.1)		Introduce Range Specifier Registry. (Section 2.1)
	Clarify that it is not ok to use a weak validator in a 206 response.		Clarify that it is not ok to use a weak validator in a 206 response.
	(Section 3.1)		(Section 3.1)
	Change ABNF productions for header fields to only define the field
	value. (Section 5)
	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. Imported ABNF		Appendix C. Imported ABNF
	The following core rules are included by reference, as defined in		The following core rules are included by reference, as defined in
	Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),		Appendix B.1 of [RFC5234]: ALPHA (letters), CR (carriage return),
	CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double		CRLF (CR LF), CTL (controls), DIGIT (decimal 0-9), DQUOTE (double
	quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any		quote), HEXDIG (hexadecimal 0-9/A-F/a-f), LF (line feed), OCTET (any
	8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII		8-bit sequence of data), SP (space), and VCHAR (any visible US-ASCII
	skipping to change at page 20, line 49		skipping to change at page 20, line 18
	Note that all rules derived from token are to be compared case-		Note that all rules derived from token are to be compared case-
	insensitively, like range-unit and acceptable-ranges.		insensitively, like range-unit and acceptable-ranges.
	The rules below are defined in [Part1]:		The rules below are defined in [Part1]:
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	token = <token, defined in [Part1], Section 3.2.4>		token = <token, defined in [Part1], Section 3.2.4>
	The rules below are defined in other parts:		The rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part2], Section 5.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>
	entity-tag = <entity-tag, defined in [Part4], Section 2.3>		entity-tag = <entity-tag, defined in [Part4], Section 2.3>
	Appendix D. Collected ABNF		Appendix D. 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 [Part2], Section 5.1>		HTTP-date = <HTTP-date, defined in [Part2], Section 8.1.1.1>
	If-Range = entity-tag / HTTP-date		If-Range = entity-tag / HTTP-date
	OWS = <OWS, defined in [Part1], Section 3.2.1>		OWS = <OWS, defined in [Part1], Section 3.2.1>
	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 22, line 30		skipping to change at page 22, line 30
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve		o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve
	'none' as byte range unit"		'none' as byte range unit"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note		o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
	introduction of new IANA registries as normative changes"		introduction of new IANA registries as normative changes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units		o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units
	vs leading zeroes vs size"		vs leading zeroes vs size"
			E.2. Since draft-ietf-httpbis-p5-range-20
			o Conformance criteria and considerations regarding error handling
			are now defined in Part 1.
	Index		Index
	2		2
	206 Partial Content (status code) 6		206 Partial Content (status code) 5
	4		4
	416 Requested Range Not Satisfiable (status code) 7		416 Requested Range Not Satisfiable (status code) 6
	A		A
	Accept-Ranges header field 9		Accept-Ranges header field 8
	C		C
	Content-Range header field 10		Content-Range header field 9
	G		G
	Grammar		Grammar
	Accept-Ranges 9		Accept-Ranges 8
	acceptable-ranges 9		acceptable-ranges 8
	byte-content-range-spec 10		byte-content-range-spec 9
	byte-range-resp-spec 10		byte-range-resp-spec 9
	byte-range-set 12		byte-range-set 12
	byte-range-spec 12		byte-range-spec 12
	byte-ranges-specifier 12		byte-ranges-specifier 12
	bytes-unit 5		bytes-unit 5
	Content-Range 10		Content-Range 9
	first-byte-pos 12		first-byte-pos 12
	If-Range 11		If-Range 11
	instance-length 10		instance-length 9
	last-byte-pos 12		last-byte-pos 12
	other-range-unit 5		other-range-unit 5
	Range 14		Range 13
	range-unit 5		range-unit 5
	ranges-specifier 12		ranges-specifier 12
	suffix-byte-range-spec 13		suffix-byte-range-spec 12
	suffix-length 13		suffix-length 12
	H
	Header Fields
	Accept-Ranges 9
	Content-Range 10
	If-Range 11
	Range 12
	I		I
	If-Range header field 11		If-Range header field 10
	M		M
	Media Type		Media Type
	multipart/byteranges 18		multipart/byteranges 17
	multipart/x-byteranges 20		multipart/x-byteranges 19
	multipart/byteranges Media Type 18		multipart/byteranges Media Type 17
	multipart/x-byteranges Media Type 20		multipart/x-byteranges Media Type 19
	R		R
	Range header field 12		Range header field 11
	S
	Status Codes
	206 Partial Content 6
	416 Requested Range Not Satisfiable 7
	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. 36 change blocks.
	119 lines changed or deleted		77 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/