draft-ietf-httpbis-p5-range-25.txt		draft-ietf-httpbis-p5-range-26.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: May 21, 2014 J. Reschke, Ed.		Expires: August 10, 2014 J. Reschke, Ed.
	greenbytes		greenbytes
	November 17, 2013		February 6, 2014
	Hypertext Transfer Protocol (HTTP/1.1): Range Requests		Hypertext Transfer Protocol (HTTP/1.1): Range Requests
	draft-ietf-httpbis-p5-range-25		draft-ietf-httpbis-p5-range-26
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is a stateless application-
	protocol for distributed, collaborative, hypertext information		level 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 May 21, 2014.		This Internet-Draft will expire on August 10, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2014 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	carefully, as they describe your rights and restrictions with respect		carefully, as they describe your rights and restrictions with respect
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	skipping to change at page 3, line 17		skipping to change at page 3, line 17
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4		1.1. Conformance and Error Handling . . . . . . . . . . . . . . 4
	1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4		1.2. Syntax Notation . . . . . . . . . . . . . . . . . . . . . 4
	2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4		2. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5		2.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . . . 5
	2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7		2.2. Other Range Units . . . . . . . . . . . . . . . . . . . . 7
	2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7		2.3. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
	3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7		3. Range Requests . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7		3.1. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 7
	3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9		3.2. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 9
	4. Responses to a Range Request . . . . . . . . . . . . . . . . . 9		4. Responses to a Range Request . . . . . . . . . . . . . . . . . 10
	4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10		4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 10
	4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12		4.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 12
	4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14		4.3. Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
	4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15		4.4. 416 Range Not Satisfiable . . . . . . . . . . . . . . . . 15
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
	5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15		5.1. Range Unit Registry . . . . . . . . . . . . . . . . . . . 15
	5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15		5.1.1. Procedure . . . . . . . . . . . . . . . . . . . . . . 15
	5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16		5.1.2. Registrations . . . . . . . . . . . . . . . . . . . . 16
	5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16		5.2. Status Code Registration . . . . . . . . . . . . . . . . . 16
	5.3. Header Field Registration . . . . . . . . . . . . . . . . 16		5.3. Header Field Registration . . . . . . . . . . . . . . . . 16
	5.4. Internet Media Type Registration . . . . . . . . . . . . . 17		5.4. Internet Media Type Registration . . . . . . . . . . . . . 17
	5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17		5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 18		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	6.1. Denial of Service Attacks using Range . . . . . . . . . . 18		6.1. Denial of Service Attacks using Range . . . . . . . . . . 18
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . . 19
	8.2. Informative References . . . . . . . . . . . . . . . . . . 19		8.2. Informative References . . . . . . . . . . . . . . . . . . 19
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 19		Appendix A. Internet Media Type multipart/byteranges . . . . . . 20
	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20		Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
	Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21		Appendix C. Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
	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) . . . . . . . . . . . . . . . . . . . . 23		publication) . . . . . . . . . . . . . . . . . . . . 23
	E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23		E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23
			E.2. Since draft-ietf-httpbis-p5-range-25 . . . . . . . . . . . 23
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	1. Introduction		1. Introduction
	Hypertext Transfer Protocol (HTTP) clients often encounter		Hypertext Transfer Protocol (HTTP) clients often encounter
	interrupted data transfers as a result of canceled requests or		interrupted data transfers as a result of canceled requests or
	dropped connections. When a client has stored a partial		dropped connections. When a client has stored a partial
	representation, it is desirable to request the remainder of that		representation, it is desirable to request the remainder of that
	representation in a subsequent request rather than transfer the		representation in a subsequent request rather than transfer the
	entire representation. Likewise, devices with limited local storage		entire representation. Likewise, devices with limited local storage
	skipping to change at page 4, line 42		skipping to change at page 4, line 42
	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].
	Conformance criteria and considerations regarding error handling are		Conformance criteria and considerations regarding error handling are
	defined in Section 2.5 of [Part1].		defined in Section 2.5 of [Part1].
	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 a list extension, defined in Section 7 of
	7 of [Part1]. Appendix C describes rules imported from other		[Part1], that allows for compact definition of comma-separated lists
	documents. Appendix D shows the collected ABNF with the list rule		using a '#' operator (similar to how the '*' operator indicates
	expanded.		repetition). Appendix C describes rules imported from other
			documents. Appendix D shows the collected grammar with all list
			operators expanded to standard ABNF notation.
	2. Range Units		2. Range Units
	A representation can be partitioned into subranges according to		A representation can be partitioned into subranges according to
	various structural units, depending on the structure inherent in the		various structural units, depending on the structure inherent in the
	representation's media type. This "range unit" is used in the		representation's media type. This "range unit" is used in the
	Accept-Ranges (Section 2.3) response header field to advertise		Accept-Ranges (Section 2.3) response header field to advertise
	support for range requests, the Range (Section 3.1) request header		support for range requests, the Range (Section 3.1) request header
	field to delineate the parts of a representation that are requested,		field to delineate the parts of a representation that are requested,
	and the Content-Range (Section 4.2) payload header field to describe		and the Content-Range (Section 4.2) payload header field to describe
	which part of a representation is being transferred.		which part of a representation is being transferred.
	range-unit = bytes-unit / other-range-unit		range-unit = bytes-unit / other-range-unit
	2.1. Byte Ranges		2.1. Byte Ranges
	Since representation data is transferred in payloads as a sequence of		Since representation data is transferred in payloads as a sequence of
	octets, a byte range is a meaningful substructure for any		octets, a byte range is a meaningful substructure for any
	representation transferable over HTTP (Section 3 of [Part2]). We		representation transferable over HTTP (Section 3 of [Part2]). The
	define the "bytes" range unit for expressing subranges of the data's		"bytes" range unit is defined for expressing subranges of the data's
	octet sequence.		octet sequence.
	bytes-unit = "bytes"		bytes-unit = "bytes"
	A byte range request can specify a single range of bytes, or a set of		A byte range request can specify a single range of bytes, or a set of
	ranges within a single representation.		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 ]
	skipping to change at page 7, line 47		skipping to change at page 7, line 47
	3.1. Range		3.1. Range
	The "Range" header field on a GET request modifies the method		The "Range" header field on a GET request modifies the method
	semantics to request transfer of only one or more subranges of the		semantics to request transfer of only one or more subranges of the
	selected representation data, rather than the entire selected		selected representation data, rather than the entire selected
	representation data.		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*VCHAR
	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 partial retrieval of large representations. A server		transfers and partial retrieval of large representations. A server
	MUST ignore a Range header field received with a request method other		MUST ignore a Range header field received with a request method other
	than GET.		than GET.
	An origin server MUST ignore a Range header field that contains a		An origin server MUST ignore a Range header field that contains a
	range unit it does not understand. A proxy MAY discard a Range		range unit it does not understand. A proxy MAY discard a Range
	skipping to change at page 9, line 39		skipping to change at page 9, line 39
	A client MUST NOT generate an If-Range header field containing an		A client MUST NOT generate an If-Range header field containing an
	entity-tag that is marked as weak. A client MUST NOT generate an If-		entity-tag that is marked as weak. A client MUST NOT generate an If-
	Range header field containing an HTTP-date unless the client has no		Range header field containing an HTTP-date unless the client has no
	entity-tag for the corresponding representation and the date is a		entity-tag for the corresponding representation and the date is a
	strong validator in the sense defined by Section 2.2.2 of [Part4].		strong validator in the sense defined by Section 2.2.2 of [Part4].
	A server that evaluates an If-Range precondition MUST use the strong		A server that evaluates an If-Range precondition MUST use the strong
	comparison function when comparing entity-tags (Section 2.3.2 of		comparison function when comparing entity-tags (Section 2.3.2 of
	[Part4]) and MUST evaluate the condition as false if an HTTP-date		[Part4]) and MUST evaluate the condition as false if an HTTP-date
	validator is provided that is not a strong validator in the sense		validator is provided that is not a strong validator in the sense
	defined by Section 2.2.2 of [Part4]. (A server can distinguish		defined by Section 2.2.2 of [Part4]. A valid entity-tag can be
	between a valid HTTP-date and any form of entity-tag by examining the		distinguished from a valid HTTP-date by examining the first two
	first two characters.)		characters for a DQUOTE.
	If the validator given in the If-Range header field matches the		If the validator given in the If-Range header field matches the
	current validator for the selected representation of the target		current validator for the selected representation of the target
	resource, then the server SHOULD process the Range header field as		resource, then the server SHOULD process the Range header field as
	requested. If the validator does not match, the server MUST ignore		requested. If the validator does not match, the server MUST ignore
	the Range header field.		the Range header field. Note that this comparison by exact match,
			including when the validator is an HTTP-date, differs from the
			"earlier than or equal to" comparison used when evaluating an If-
			Unmodified-Since conditional.
	4. Responses to a Range Request		4. Responses to a Range Request
	4.1. 206 Partial Content		4.1. 206 Partial Content
	The 206 (Partial Content) status code indicates that the server is		The 206 (Partial Content) status code indicates that the server is
	successfully fulfilling a range request for the target resource by		successfully fulfilling a range request for the target resource by
	transferring one or more parts of the selected representation that		transferring one or more parts of the selected representation that
	correspond to the satisfiable ranges found in the request's Range		correspond to the satisfiable ranges found in the request's Range
	header field (Section 3.1).		header field (Section 3.1).
	If a single part is being transferred, the server generating the 206		If a single part is being transferred, the server generating the 206
	response MUST generate a Content-Range header field, describing what		response MUST generate a Content-Range header field, describing what
	skipping to change at page 17, line 33		skipping to change at page 17, line 33
	"multipart/byteranges". The following is to be registered with IANA.		"multipart/byteranges". The following is to be registered with IANA.
	5.4.1. Internet Media Type multipart/byteranges		5.4.1. Internet Media Type multipart/byteranges
	Type name: multipart		Type name: multipart
	Subtype name: byteranges		Subtype name: byteranges
	Required parameters: boundary		Required parameters: boundary
	Optional parameters: none		Optional parameters: N/A
	Encoding considerations: only "7bit", "8bit", or "binary" are		Encoding considerations: only "7bit", "8bit", or "binary" are
	permitted		permitted
	Security considerations: none		Security considerations: see Section 6
	Interoperability considerations: none		Interoperability considerations: N/A
	Published specification: This specification (see Appendix A).		Published specification: This specification (see Appendix A).
	Applications that use this media type: HTTP components supporting		Applications that use this media type: HTTP components supporting
	multiple ranges in a single request.		multiple ranges in a single request.
			Fragment identifier considerations: N/A
	Additional information:		Additional information:
	Magic number(s): none		Deprecated alias names for this type: N/A
	File extension(s): none
	Macintosh file type code(s): none		Magic number(s): N/A
			File extension(s): N/A
			Macintosh file type code(s): N/A
	Person and email address to contact for further information: See		Person and email address to contact for further information: See
	Authors Section.		Authors Section.
	Intended usage: COMMON		Intended usage: COMMON
	Restrictions on usage: none		Restrictions on usage: N/A
	Author: See Authors Section.		Author: See Authors Section.
	Change controller: IESG		Change controller: IESG
	6. Security Considerations		6. Security Considerations
	This section is meant to inform developers, information providers,		This section is meant to inform developers, information providers,
	and users of known security concerns specific to the HTTP/1.1 range		and users of known security concerns specific to the HTTP range
	request mechanisms. More general security considerations are		request mechanisms. More general security considerations are
	addressed in HTTP messaging [Part1] and semantics [Part2].		addressed in HTTP messaging [Part1] and semantics [Part2].
	6.1. Denial of Service Attacks using Range		6.1. Denial of Service Attacks using Range
	Unconstrained multiple range requests are susceptible to denial of		Unconstrained multiple range requests are susceptible to denial of
	service attacks because the effort required to request many		service attacks because the effort required to request many
	overlapping ranges of the same data is tiny compared to the time,		overlapping ranges of the same data is tiny compared to the time,
	memory, and bandwidth consumed by attempting to serve the requested		memory, and bandwidth consumed by attempting to serve the requested
	data in many parts. Servers ought to ignore, coalesce, or reject		data in many parts. Servers ought to ignore, coalesce, or reject
	skipping to change at page 18, line 44		skipping to change at page 19, line 4
	overlapping ranges or for many small ranges in a single set,		overlapping ranges or for many small ranges in a single set,
	particularly when the ranges are requested out of order for no		particularly when the ranges are requested out of order for no
	apparent reason. Multipart range requests are not designed to		apparent reason. Multipart range requests are not designed to
	support random access.		support random access.
	7. Acknowledgments		7. Acknowledgments
	See Section 10 of [Part1].		See Section 10 of [Part1].
	8. References		8. References
	8.1. Normative References		8.1. Normative References
	[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part1] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Message Syntax and Routing",		Protocol (HTTP/1.1): Message Syntax and Routing",
	draft-ietf-httpbis-p1-messaging-25 (work in progress),		draft-ietf-httpbis-p1-messaging-26 (work in progress),
	November 2013.		February 2014.
	[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part2] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Semantics and Content",		Protocol (HTTP/1.1): Semantics and Content",
	draft-ietf-httpbis-p2-semantics-25 (work in progress),		draft-ietf-httpbis-p2-semantics-26 (work in progress),
	November 2013.		February 2014.
	[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer		[Part4] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
	Protocol (HTTP/1.1): Conditional Requests",		Protocol (HTTP/1.1): Conditional Requests",
	draft-ietf-httpbis-p4-conditional-25 (work in progress),		draft-ietf-httpbis-p4-conditional-26 (work in progress),
	November 2013.		February 2014.
	[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,		[Part6] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
	Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",		Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
	draft-ietf-httpbis-p6-cache-25 (work in progress),		draft-ietf-httpbis-p6-cache-26 (work in progress),
	November 2013.		February 2014.
	[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 22, line 41		skipping to change at page 22, line 41
	complete-length = 1*DIGIT		complete-length = 1*DIGIT
	entity-tag = <entity-tag, defined in [Part4], Section 2.3>		entity-tag = <entity-tag, defined in [Part4], Section 2.3>
	first-byte-pos = 1*DIGIT		first-byte-pos = 1*DIGIT
	last-byte-pos = 1*DIGIT		last-byte-pos = 1*DIGIT
	other-content-range = other-range-unit SP other-range-resp		other-content-range = other-range-unit SP other-range-resp
	other-range-resp = *CHAR		other-range-resp = *CHAR
	other-range-set = 1*CHAR		other-range-set = 1*VCHAR
	other-range-unit = token		other-range-unit = token
	other-ranges-specifier = other-range-unit "=" other-range-set		other-ranges-specifier = other-range-unit "=" other-range-set
	range-unit = bytes-unit / other-range-unit		range-unit = bytes-unit / other-range-unit
	suffix-byte-range-spec = "-" suffix-length		suffix-byte-range-spec = "-" suffix-length
	suffix-length = 1*DIGIT		suffix-length = 1*DIGIT
	token = <token, defined in [Part1], Section 3.2.6>		token = <token, defined in [Part1], Section 3.2.6>
	skipping to change at page 23, line 23		skipping to change at page 23, line 23
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/506>: "APPSDIR		o <http://tools.ietf.org/wg/httpbis/trac/ticket/506>: "APPSDIR
	review of draft-ietf-httpbis-p5-range-24"		review of draft-ietf-httpbis-p5-range-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value		o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
	parsing"		parsing"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/508>: "broken		o <http://tools.ietf.org/wg/httpbis/trac/ticket/508>: "broken
	sentence in description of 206"		sentence in description of 206"
			E.2. Since draft-ietf-httpbis-p5-range-25
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/526>: "check media
			type registration templates"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/527>: "use of CHAR
			for other-range-set"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/538>: "add
			'stateless' to Abstract"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/542>: "improve
			introduction of list rule"
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/549>: "augment
			security considerations with pointers to current research"
	Index		Index
	2		2
	206 Partial Content (status code) 10		206 Partial Content (status code) 10
	4		4
	416 Range Not Satisfiable (status code) 15		416 Range Not Satisfiable (status code) 15
	A		A
	Accept-Ranges header field 7		Accept-Ranges header field 7
	skipping to change at page 24, line 19		skipping to change at page 24, line 39
	ranges-specifier 5		ranges-specifier 5
	suffix-byte-range-spec 6		suffix-byte-range-spec 6
	suffix-length 6		suffix-length 6
	unsatisfied-range 12		unsatisfied-range 12
	I		I
	If-Range header field 9		If-Range header field 9
	M		M
	Media Type		Media Type
	multipart/byteranges 17, 19		multipart/byteranges 17, 20
	multipart/x-byteranges 20		multipart/x-byteranges 20
	multipart/byteranges Media Type 17, 19		multipart/byteranges Media Type 17, 20
	multipart/x-byteranges Media Type 20		multipart/x-byteranges Media Type 20
	R		R
	Range header field 7		Range header field 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
End of changes. 34 change blocks.
	44 lines changed or deleted		74 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/