draft-ietf-httpbis-p5-range-24.txt		draft-ietf-httpbis-p5-range-25.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: March 29, 2014 J. Reschke, Ed.		Expires: May 21, 2014 J. Reschke, Ed.
	greenbytes		greenbytes
	September 25, 2013		November 17, 2013
	Hypertext Transfer Protocol (HTTP/1.1): Range Requests		Hypertext Transfer Protocol (HTTP/1.1): Range Requests
	draft-ietf-httpbis-p5-range-24		draft-ietf-httpbis-p5-range-25
	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.5.		The changes in this draft are summarized in Appendix E.1.
	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 March 29, 2014.		This Internet-Draft will expire on May 21, 2014.
	Copyright Notice		Copyright Notice
	Copyright (c) 2013 IETF Trust and the persons identified as the		Copyright (c) 2013 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 28		skipping to change at page 3, line 28
	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
	6. Security Considerations . . . . . . . . . . . . . . . . . . . 17		5.4. Internet Media Type Registration . . . . . . . . . . . . . 17
	6.1. Denial of Service Attacks using Range . . . . . . . . . . 17		5.4.1. Internet Media Type multipart/byteranges . . . . . . . 17
	7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 17		6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17		6.1. Denial of Service Attacks using Range . . . . . . . . . . 18
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 17		7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 18
	8.2. Informative References . . . . . . . . . . . . . . . . . . 18		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 18		8.1. Normative References . . . . . . . . . . . . . . . . . . . 18
			8.2. Informative References . . . . . . . . . . . . . . . . . . 19
			Appendix A. Internet Media Type multipart/byteranges . . . . . . 19
	Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20		Appendix B. Changes from RFC 2616 . . . . . . . . . . . . . . . . 20
	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-19 . . . . . . . . . . . 23		E.1. Since draft-ietf-httpbis-p5-range-24 . . . . . . . . . . . 23
	E.2. Since draft-ietf-httpbis-p5-range-20 . . . . . . . . . . . 23		Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
	E.3. Since draft-ietf-httpbis-p5-range-21 . . . . . . . . . . . 23
	E.4. Since draft-ietf-httpbis-p5-range-22 . . . . . . . . . . . 24
	E.5. Since draft-ietf-httpbis-p5-range-23 . . . . . . . . . . . 24
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
	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
	might benefit from being able to request only a subset of a larger		might benefit from being able to request only a subset of a larger
	skipping to change at page 6, line 45		skipping to change at page 6, line 45
	bytes=500-700,601-999		bytes=500-700,601-999
	If a valid byte-range-set includes at least one byte-range-spec with		If a valid byte-range-set includes at least one byte-range-spec with
	a first-byte-pos that is less than the current length of the		a first-byte-pos that is less than the current length of the
	representation, or at least one suffix-byte-range-spec with a non-		representation, or at least one suffix-byte-range-spec with a non-
	zero suffix-length, then the byte-range-set is satisfiable.		zero suffix-length, then the byte-range-set is satisfiable.
	Otherwise, the byte-range-set is unsatisfiable.		Otherwise, the byte-range-set is unsatisfiable.
	In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-		In the byte range syntax, first-byte-pos, last-byte-pos, and suffix-
	length are expressed as decimal number of octets. Since there is no		length are expressed as decimal number of octets. Since there is no
	predefined limit to the length of a payload, recipients ought to		predefined limit to the length of a payload, recipients MUST
	anticipate potentially large decimal numerals and prevent parsing		anticipate potentially large decimal numerals and prevent parsing
	errors due to integer conversion overflows.		errors due to integer conversion overflows.
	2.2. Other Range Units		2.2. Other Range Units
	Range units are intended to be extensible. New range units ought to		Range units are intended to be extensible. New range units ought to
	be registered with IANA, as defined in Section 5.1.		be registered with IANA, as defined in Section 5.1.
	other-range-unit = token		other-range-unit = token
	skipping to change at page 7, line 30		skipping to change at page 7, line 30
	An origin server that supports byte-range requests for a given target		An origin server that supports byte-range requests for a given target
	resource MAY send		resource MAY send
	Accept-Ranges: bytes		Accept-Ranges: bytes
	to indicate what range units are supported. A client MAY generate		to indicate what range units are supported. A client MAY generate
	range requests without having received this header field for the		range requests without having received this header field for the
	resource involved. Range units are defined in Section 2.		resource involved. Range units are defined in Section 2.
	A server that does not support any kind of range request for the		A server that does not support any kind of range request for the
	target resource resource MAY send		target resource MAY send
	Accept-Ranges: none		Accept-Ranges: none
	to advise the client not to attempt a range request.		to advise the client not to attempt a range request.
	3. Range Requests		3. Range Requests
	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
	skipping to change at page 11, line 24		skipping to change at page 11, line 24
	...the first range...		...the first range...
	--THIS_STRING_SEPARATES		--THIS_STRING_SEPARATES
	Content-Type: application/pdf		Content-Type: application/pdf
	Content-Range: bytes 7000-7999/8000		Content-Range: bytes 7000-7999/8000
	...the second range		...the second range
	--THIS_STRING_SEPARATES--		--THIS_STRING_SEPARATES--
	When multiple ranges are requested, a server MAY coalesce any of the		When multiple ranges are requested, a server MAY coalesce any of the
	ranges that overlap or that are separated by a gap that is smaller		ranges that overlap, or that are separated by a gap that is smaller
	than the overhead of sending multiple parts, regardless of the order		than the overhead of sending multiple parts, regardless of the order
	in which the corresponding byte-range-spec appeared in the received		in which the corresponding byte-range-spec appeared in the received
	Range header field. Since the typical overhead between parts of a		Range header field. Since the typical overhead between parts of a
	multipart/byteranges payload is around 80 bytes, depending on the		multipart/byteranges payload is around 80 bytes, depending on the
	selected representation's media type and the chosen boundary		selected representation's media type and the chosen boundary
	parameter length, it can be less efficient to transfer many small		parameter length, it can be less efficient to transfer many small
	disjoint parts than it is to transfer the entire selected		disjoint parts than it is to transfer the entire selected
	representation.		representation.
	A server MUST NOT generate a multipart response to a request for a		A server MUST NOT generate a multipart response to a request for a
	skipping to change at page 12, line 19		skipping to change at page 12, line 19
	Vary.		Vary.
	If a 206 is generated in response to a request with an If-Range		If a 206 is generated in response to a request with an If-Range
	header field, the sender SHOULD NOT generate other representation		header field, the sender SHOULD NOT generate other representation
	header fields beyond those required above, because the client is		header fields beyond those required above, because the client is
	understood to already have a prior response containing those header		understood to already have a prior response containing those header
	fields. Otherwise, the sender MUST generate all of the		fields. Otherwise, the sender MUST generate all of the
	representation header fields that would have been sent in a 200 (OK)		representation header fields that would have been sent in a 200 (OK)
	response to the same request.		response to the same request.
	A 206 response is cacheable unless otherwise indicated by explicit		A 206 response is cacheable by default; i.e., unless otherwise
	cache controls (see Section 4.2.2 of [Part6]).		indicated by explicit cache controls (see Section 4.2.2 of [Part6]).
	4.2. Content-Range		4.2. Content-Range
	The "Content-Range" header field is sent in a single part 206		The "Content-Range" header field is sent in a single part 206
	(Partial Content) response to indicate the partial range of the		(Partial Content) response to indicate the partial range of the
	selected representation enclosed as the message payload, sent in each		selected representation enclosed as the message payload, sent in each
	part of a multipart 206 response to indicate the range enclosed		part of a multipart 206 response to indicate the range enclosed
	within each body part, and sent in 416 (Range Not Satisfiable)		within each body part, and sent in 416 (Range Not Satisfiable)
	responses to provide information about the selected representation.		responses to provide information about the selected representation.
	skipping to change at page 15, line 42		skipping to change at page 15, line 42
	received a complete representation. Thus, clients cannot depend		received a complete representation. Thus, clients cannot depend
	on receiving a 416 (Range Not Satisfiable) response even when it		on receiving a 416 (Range Not Satisfiable) response even when it
	is most appropriate.		is most appropriate.
	5. IANA Considerations		5. IANA Considerations
	5.1. Range Unit Registry		5.1. Range Unit Registry
	The HTTP Range Unit Registry defines the name space for the range		The HTTP Range Unit Registry defines the name space for the range
	unit names and refers to their corresponding specifications. The		unit names and refers to their corresponding specifications. The
	registry will be created and maintained at		registry will be created and maintained at (the suggested URI)
	<http://www.iana.org/assignments/http-parameters>.		<http://www.iana.org/assignments/http-parameters>.
	5.1.1. Procedure		5.1.1. Procedure
	Registration of an HTTP Range Unit MUST include the following fields:		Registration of an HTTP Range Unit MUST include the following fields:
	o Name		o Name
	o Description		o Description
	o Pointer to specification text		o Pointer to specification text
	skipping to change at page 17, line 17		skipping to change at page 17, line 17
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	| Accept-Ranges | http | standard | Section 2.3 |		| Accept-Ranges | http | standard | Section 2.3 |
	| Content-Range | http | standard | Section 4.2 |		| Content-Range | http | standard | Section 4.2 |
	| If-Range | http | standard | Section 3.2 |		| If-Range | http | standard | Section 3.2 |
	| Range | http | standard | Section 3.1 |		| Range | http | standard | Section 3.1 |
	+-------------------+----------+----------+-------------+		+-------------------+----------+----------+-------------+
	The change controller is: "IETF (iesg@ietf.org) - Internet		The change controller is: "IETF (iesg@ietf.org) - Internet
	Engineering Task Force".		Engineering Task Force".
			5.4. Internet Media Type Registration
			IANA maintains the registry of Internet media types [BCP13] at
			<http://www.iana.org/assignments/media-types>.
			This document serves as the specification for the Internet media type
			"multipart/byteranges". The following is to be registered with IANA.
			5.4.1. Internet Media Type multipart/byteranges
			Type name: multipart
			Subtype name: byteranges
			Required parameters: boundary
			Optional parameters: none
			Encoding considerations: only "7bit", "8bit", or "binary" are
			permitted
			Security considerations: none
			Interoperability considerations: none
			Published specification: This specification (see Appendix A).
			Applications that use this media type: HTTP components supporting
			multiple ranges in a single request.
			Additional information:
			Magic number(s): none
			File extension(s): none
			Macintosh file type code(s): none
			Person and email address to contact for further information: See
			Authors Section.
			Intended usage: COMMON
			Restrictions on usage: none
			Author: See Authors Section.
			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/1.1 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
	skipping to change at page 17, line 47		skipping to change at page 18, line 49
	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-24 (work in progress),		draft-ietf-httpbis-p1-messaging-25 (work in progress),
	September 2013.		November 2013.
	[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-24 (work in progress),		draft-ietf-httpbis-p2-semantics-25 (work in progress),
	September 2013.		November 2013.
	[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-24 (work in progress),		draft-ietf-httpbis-p4-conditional-25 (work in progress),
	September 2013.		November 2013.
	[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-24 (work in progress),		draft-ietf-httpbis-p6-cache-25 (work in progress),
	September 2013.		November 2013.
	[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 18, line 49		skipping to change at page 20, line 4
	[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an		[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
	IANA Considerations Section in RFCs", BCP 26, RFC 5226,		IANA Considerations Section in RFCs", BCP 26, RFC 5226,
	May 2008.		May 2008.
	Appendix A. Internet Media Type multipart/byteranges		Appendix A. Internet Media Type multipart/byteranges
	When a 206 (Partial Content) response message includes the content of		When a 206 (Partial Content) response message includes the content of
	multiple ranges, they are transmitted as body parts in a multipart		multiple ranges, they are transmitted as body parts in a multipart
	message body ([RFC2046], Section 5.1) with the media type of		message body ([RFC2046], Section 5.1) with the media type of
	"multipart/byteranges". The following definition is to be registered		"multipart/byteranges".
	with IANA [BCP13].
	The multipart/byteranges media type includes one or more body parts,		The multipart/byteranges media type includes one or more body parts,
	each with its own Content-Type and Content-Range fields. The		each with its own Content-Type and Content-Range fields. The
	required boundary parameter specifies the boundary string used to		required boundary parameter specifies the boundary string used to
	separate each body part.		separate each body part.
	Type name: multipart
	Subtype name: byteranges
	Required parameters: boundary
	Optional parameters: none
	Encoding considerations: only "7bit", "8bit", or "binary" are
	permitted
	Security considerations: none
	Interoperability considerations: none
	Published specification: This specification (see Appendix A).
	Applications that use this media type: HTTP components supporting
	multiple ranges in a single request.
	Additional information:
	Magic number(s): none
	File extension(s): none
	Macintosh file type code(s): none
	Person and email address to contact for further information: See
	Authors Section.
	Intended usage: COMMON
	Restrictions on usage: none
	Author: See Authors Section.
	Change controller: IESG
	Implementation Notes:		Implementation Notes:
	1. Additional CRLFs might precede the first boundary string in the		1. Additional CRLFs might precede the first boundary string in the
	body.		body.
	2. Although [RFC2046] permits the boundary string to be quoted, some		2. Although [RFC2046] permits the boundary string to be quoted, some
	existing implementations handle a quoted boundary string		existing implementations handle a quoted boundary string
	incorrectly.		incorrectly.
	3. A number of clients and servers were coded to an early draft of		3. A number of clients and servers were coded to an early draft of
	skipping to change at page 23, line 7		skipping to change at page 23, line 7
	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>
	unsatisfied-range = "*/" complete-length		unsatisfied-range = "*/" complete-length
	Appendix E. Change Log (to be removed by RFC Editor before publication)		Appendix E. Change Log (to be removed by RFC Editor before publication)
	Changes up to the first Working Group Last Call draft are summarized		Changes up to the IETF Last Call draft are summarized in <http://
	in <http://tools.ietf.org/html/		tools.ietf.org/html/draft-ietf-httpbis-p5-range-24#appendix-E>.
	draft-ietf-httpbis-p5-range-19#appendix-D>.
	E.1. Since draft-ietf-httpbis-p5-range-19
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/358>: "ABNF list
	expansion code problem"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/361>: "ABNF
	requirements for recipients"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/367>: "reserve
	'none' as byte range unit"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/368>: "note
	introduction of new IANA registries as normative changes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/369>: "range units
	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.
	E.3. Since draft-ietf-httpbis-p5-range-21
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/175>: "Security
	consideration: range flooding"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/223>: "Allowing
	heuristic caching for new status codes"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/311>: "Add
	limitations to Range to reduce its use as a denial-of-service
	tool"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/407>: "416 and
	multipart/byteranges"
	E.4. Since draft-ietf-httpbis-p5-range-22		E.1. Since draft-ietf-httpbis-p5-range-24
	Closed issues:		Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/436>: "explain list		o <http://tools.ietf.org/wg/httpbis/trac/ticket/506>: "APPSDIR
	expansion in ABNF appendices"		review of draft-ietf-httpbis-p5-range-24"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/437>: "incorrect
	example dates"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/438>: "media type
	registration template issues"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/462>: "Editorial
	suggestions"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/485>: "MUSTs and
	other feedback"
	E.5. Since draft-ietf-httpbis-p5-range-23
	Closed issues:
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/489>: "is P5's		o <http://tools.ietf.org/wg/httpbis/trac/ticket/507>: "integer value
	definition of strong validator consistent with P4?"		parsing"
	o <http://tools.ietf.org/wg/httpbis/trac/ticket/490>: "p5 editorial		o <http://tools.ietf.org/wg/httpbis/trac/ticket/508>: "broken
	comments"		sentence in description of 206"
	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
	skipping to change at page 25, line 30		skipping to change at page 24, line 19
	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 18		multipart/byteranges 17, 19
	multipart/x-byteranges 20		multipart/x-byteranges 20
	multipart/byteranges Media Type 18		multipart/byteranges Media Type 17, 19
	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. 26 change blocks.
	142 lines changed or deleted		90 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/