draft-ietf-httpbis-p5-range-04.txt		draft-ietf-httpbis-p5-range-05.txt
	Network Working Group R. Fielding, Ed.		Network Working Group R. Fielding, Ed.
	Internet-Draft Day Software		Internet-Draft Day Software
	Obsoletes: 2616 (if approved) J. Gettys		Obsoletes: 2616 (if approved) J. Gettys
	Intended status: Standards Track One Laptop per Child		Intended status: Standards Track One Laptop per Child
	Expires: March 2, 2009 J. Mogul		Expires: May 20, 2009 J. Mogul
	HP		HP
	H. Frystyk		H. Frystyk
	Microsoft		Microsoft
	L. Masinter		L. Masinter
	Adobe Systems		Adobe Systems
	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 29, 2008		November 16, 2008
	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-04		draft-ietf-httpbis-p5-range-05
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 49		skipping to change at page 1, line 49
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on March 2, 2009.		This Internet-Draft will expire on May 20, 2009.
	Abstract		Abstract
	The Hypertext Transfer Protocol (HTTP) is an application-level		The Hypertext Transfer Protocol (HTTP) is an application-level
	protocol for distributed, collaborative, hypermedia information		protocol for distributed, collaborative, hypermedia 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. Part 5 defines		"HTTP/1.1" and, taken together, obsoletes RFC 2616. Part 5 defines
	range-specific requests and the rules for constructing and combining		range-specific requests and the rules for constructing and combining
	responses to those requests.		responses to those requests.
	Editorial Note (To be removed by RFC Editor)		Editorial Note (To be removed by RFC Editor)
	Discussion of this draft should take place on the HTTPBIS working		Discussion of this draft should take place on the HTTPBIS working
	group mailing list (ietf-http-wg@w3.org). The current issues list is		group mailing list (ietf-http-wg@w3.org). The current issues list is
	at <http://www.tools.ietf.org/wg/httpbis/trac/report/11> and related		at <http://tools.ietf.org/wg/httpbis/trac/report/11> and related
	documents (including fancy diffs) can be found at		documents (including fancy diffs) can be found at
	<http://www.tools.ietf.org/wg/httpbis/>.		<http://tools.ietf.org/wg/httpbis/>.
	The changes in this draft are summarized in Appendix C.4.		The changes in this draft are summarized in Appendix C.6.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4		1.1. Requirements . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Notational Conventions and Generic Grammar . . . . . . . . . . 4		2. Notational Conventions and Generic Grammar . . . . . . . . . . 4
	3. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5		3. Range Units . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5		4. Status Code Definitions . . . . . . . . . . . . . . . . . . . 5
	4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5		4.1. 206 Partial Content . . . . . . . . . . . . . . . . . . . 5
	4.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6		4.2. 416 Requested Range Not Satisfiable . . . . . . . . . . . 6
	5. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6		5. Combining Byte Ranges . . . . . . . . . . . . . . . . . . . . 6
	6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7		6. Header Field Definitions . . . . . . . . . . . . . . . . . . . 7
	6.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7		6.1. Accept-Ranges . . . . . . . . . . . . . . . . . . . . . . 7
	6.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8		6.2. Content-Range . . . . . . . . . . . . . . . . . . . . . . 8
	6.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.3. If-Range . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10		6.4. Range . . . . . . . . . . . . . . . . . . . . . . . . . . 10
	6.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 10		6.4.1. Byte Ranges . . . . . . . . . . . . . . . . . . . . . 11
	6.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12		6.4.2. Range Retrieval Requests . . . . . . . . . . . . . . . 12
	7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13		7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
	7.1. Message Header Registration . . . . . . . . . . . . . . . 13		7.1. Message Header Registration . . . . . . . . . . . . . . . 13
	8. Security Considerations . . . . . . . . . . . . . . . . . . . 13		8. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
	10.1. Normative References . . . . . . . . . . . . . . . . . . . 14		10.1. Normative References . . . . . . . . . . . . . . . . . . . 14
	10.2. Informative References . . . . . . . . . . . . . . . . . . 15		10.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix A. Internet Media Type multipart/byteranges . . . . . . 15		Appendix A. Internet Media Type multipart/byteranges . . . . . . 15
	Appendix B. Compatibility with Previous Versions . . . . . . . . 17		Appendix B. Compatibility with Previous Versions . . . . . . . . 17
	B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17		B.1. Changes from RFC 2068 . . . . . . . . . . . . . . . . . . 17
	B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17		B.2. Changes from RFC 2616 . . . . . . . . . . . . . . . . . . 17
	Appendix C. Change Log (to be removed by RFC Editor before		Appendix C. Change Log (to be removed by RFC Editor before
	publication) . . . . . . . . . . . . . . . . . . . . 17		publication) . . . . . . . . . . . . . . . . . . . . 17
	C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17		C.1. Since RFC2616 . . . . . . . . . . . . . . . . . . . . . . 17
	C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 18		C.2. Since draft-ietf-httpbis-p5-range-00 . . . . . . . . . . . 18
	C.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 18		C.3. Since draft-ietf-httpbis-p5-range-01 . . . . . . . . . . . 18
	C.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 18		C.4. Since draft-ietf-httpbis-p5-range-02 . . . . . . . . . . . 18
	C.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 18		C.5. Since draft-ietf-httpbis-p5-range-03 . . . . . . . . . . . 18
	Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18		C.6. Since draft-ietf-httpbis-p5-range-04 . . . . . . . . . . . 18
			Index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
	Intellectual Property and Copyright Statements . . . . . . . . . . 23		Intellectual Property and Copyright Statements . . . . . . . . . . 23
	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 cache has		of cancelled requests or dropped connections. When a cache 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
	skipping to change at page 4, line 49		skipping to change at page 4, line 49
	REQUIRED level and all the SHOULD level requirements for its		REQUIRED level and all the SHOULD level requirements for its
	protocols is said to be "unconditionally compliant"; one that		protocols is said to be "unconditionally compliant"; one that
	satisfies all the MUST level requirements but not all the SHOULD		satisfies all the MUST level requirements but not all the SHOULD
	level requirements for its protocols is said to be "conditionally		level requirements for its protocols is said to be "conditionally
	compliant."		compliant."
	2. Notational Conventions and Generic Grammar		2. Notational Conventions and Generic Grammar
	This specification uses the ABNF syntax defined in Section 2.1 of		This specification uses the ABNF syntax defined in Section 2.1 of
	[Part1] and the core rules defined in Section 2.2 of [Part1]:		[Part1] and the core rules defined in Section 2.2 of [Part1]:
	[[abnf.dep: ABNF syntax and basic rules will be adopted from RFC
	5234, see <http://tools.ietf.org/wg/httpbis/trac/ticket/36>.]]
	DIGIT = <DIGIT, defined in [Part1], Section 2.2>		DIGIT = <DIGIT, defined in [Part1], Section 2.2>
	SP = <SP, defined in [Part1], Section 2.2>		SP = <SP, defined in [Part1], Section 2.2>
	token = <token, defined in [Part1], Section 2.2>		token = <token, defined in [Part1], Section 2.2>
			OWS = <OWS, defined in [Part1], Section 2.2>
	The ABNF rules below are defined in other parts:		The ABNF rules below are defined in other parts:
	HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>		HTTP-date = <HTTP-date, defined in [Part1], Section 3.3.1>
	entity-tag = <entity-tag, defined in [Part4], Section 3>		entity-tag = <entity-tag, defined in [Part4], Section 3>
	3. Range Units		3. 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
	response entity be included within the response. HTTP/1.1 uses range		response entity be included within the response. HTTP/1.1 uses range
	units in the Range (Section 6.4) and Content-Range (Section 6.2)		units in the Range (Section 6.4) and Content-Range (Section 6.2)
	header fields. An entity can be broken down into subranges according		header fields. An entity can be broken down into subranges according
	to various structural units.		to various structural units.
	range-unit = bytes-unit | other-range-unit		range-unit = bytes-unit / other-range-unit
	bytes-unit = "bytes"		bytes-unit = "bytes"
	other-range-unit = token		other-range-unit = token
	The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1		The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1
	implementations MAY ignore ranges specified using other units.		implementations MAY ignore ranges specified using other units.
	HTTP/1.1 has been designed to allow implementations of applications		HTTP/1.1 has been designed to allow implementations of applications
	that do not depend on knowledge of ranges.		that do not depend on knowledge of ranges.
	4. Status Code Definitions		4. Status Code Definitions
	skipping to change at page 6, line 32		skipping to change at page 6, line 30
	content if the ETag or Last-Modified headers do not match exactly,		content if the ETag or Last-Modified headers do not match exactly,
	see Section 5.		see Section 5.
	A cache that does not support the Range and Content-Range headers		A cache that does not support the Range and Content-Range headers
	MUST NOT cache 206 (Partial Content) responses.		MUST NOT cache 206 (Partial Content) responses.
	4.2. 416 Requested Range Not Satisfiable		4.2. 416 Requested Range Not Satisfiable
	A server SHOULD return a response with this status code if a request		A server SHOULD return a response with this status code if a request
	included a Range request-header field (Section 6.4), and none of the		included a Range request-header field (Section 6.4), and none of the
	range-specifier values in this field overlap the current extent of		ranges-specifier values in this field overlap the current extent of
	the selected resource, and the request did not include an If-Range		the selected resource, and the request did not include an If-Range
	request-header field. (For byte-ranges, this means that the first-		request-header field. (For byte-ranges, this means that the first-
	byte-pos of all of the byte-range-spec values were greater than the		byte-pos of all of the byte-range-spec values were greater than the
	current length of the selected resource.)		current length of the selected resource.)
	When this status code is returned for a byte-range request, the		When this status code is returned for a byte-range request, the
	response SHOULD include a Content-Range entity-header field		response SHOULD include a Content-Range entity-header field
	specifying the current length of the selected resource (see		specifying the current length of the selected resource (see
	Section 6.2). This response MUST NOT use the multipart/byteranges		Section 6.2). This response MUST NOT use the multipart/byteranges
	content-type.		content-type.
	skipping to change at page 7, line 32		skipping to change at page 7, line 29
	This section defines the syntax and semantics of HTTP/1.1 header		This section defines the syntax and semantics of HTTP/1.1 header
	fields related to range requests and partial responses.		fields related to range requests and partial responses.
	For entity-header fields, both sender and recipient refer to either		For entity-header fields, both sender and recipient refer to either
	the client or the server, depending on who sends and who receives the		the client or the server, depending on who sends and who receives the
	entity.		entity.
	6.1. Accept-Ranges		6.1. Accept-Ranges
	The Accept-Ranges response-header field allows the server to indicate		The response-header "Accept-Ranges" field allows the server to
	its acceptance of range requests for a resource:		indicate its acceptance of range requests for a resource:
	Accept-Ranges = "Accept-Ranges" ":" acceptable-ranges		Accept-Ranges = "Accept-Ranges" ":" OWS Accept-Ranges-v
	acceptable-ranges = 1#range-unit | "none"		Accept-Ranges-v = acceptable-ranges
			acceptable-ranges = 1#range-unit / "none"
	Origin servers that accept byte-range requests MAY send		Origin servers that accept byte-range requests MAY send
	Accept-Ranges: bytes		Accept-Ranges: bytes
	but are not required to do so. Clients MAY generate byte-range		but are not required to do so. Clients MAY generate byte-range
	requests without having received this header for the resource		requests without having received this header for the resource
	involved. Range units are defined in Section 3.		involved. Range units are defined in Section 3.
	Servers that do not accept any kind of range request for a resource		Servers that do not accept any kind of range request for a resource
	MAY send		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.
	6.2. Content-Range		6.2. Content-Range
	The Content-Range entity-header is sent with a partial entity-body to		The entity-header "Content-Range" is sent with a partial entity-body
	specify where in the full entity-body the partial body should be		to specify where in the full entity-body the partial body should be
	applied. Range units are defined in Section 3.		applied. Range units are defined in Section 3.
	Content-Range = "Content-Range" ":" content-range-spec		Content-Range = "Content-Range" ":" OWS Content-Range-v
			Content-Range-v = content-range-spec
	content-range-spec = byte-content-range-spec		content-range-spec = byte-content-range-spec
	byte-content-range-spec = bytes-unit SP		byte-content-range-spec = bytes-unit SP
	byte-range-resp-spec "/"		byte-range-resp-spec "/"
	( instance-length | "*" )		( instance-length / "*" )
	byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)		byte-range-resp-spec = (first-byte-pos "-" last-byte-pos)
	| "*"		/ "*"
	instance-length = 1*DIGIT		instance-length = 1*DIGIT
	The header SHOULD indicate the total length of the full entity-body,		The header SHOULD indicate the total length of the full entity-body,
	unless this length is unknown or difficult to determine. The		unless this length is unknown or difficult to determine. The
	asterisk "*" character means that the instance-length is unknown at		asterisk "*" character means that the instance-length is unknown at
	the time when the response was generated.		the time when the response was generated.
	Unlike byte-ranges-specifier values (see Section 6.4.1), a byte-		Unlike byte-ranges-specifier values (see Section 6.4.1), a byte-
	range-resp-spec MUST only specify one range, and MUST contain		range-resp-spec MUST only specify one range, and MUST contain
	skipping to change at page 10, line 25		skipping to change at page 10, line 25
	6.3. If-Range		6.3. If-Range
	If a client has a partial copy of an entity in its cache, and wishes		If a client has a partial copy of an entity in its cache, and wishes
	to have an up-to-date copy of the entire entity in its cache, it		to have an up-to-date copy of the entire entity in its cache, it
	could use the Range request-header with a conditional GET (using		could use the Range request-header with a conditional GET (using
	either or both of If-Unmodified-Since and If-Match.) However, if the		either or both of If-Unmodified-Since and If-Match.) However, if the
	condition fails because the entity has been modified, the client		condition fails because the entity has been modified, the client
	would then have to make a second request to obtain the entire current		would then have to make a second request to obtain the entire current
	entity-body.		entity-body.
	The If-Range header allows a client to "short-circuit" the second		The request header "If-Range" allows a client to "short-circuit" the
	request. Informally, its meaning is `if the entity is unchanged,		second request. Informally, its meaning is `if the entity is
	send me the part(s) that I am missing; otherwise, send me the entire		unchanged, send me the part(s) that I am missing; otherwise, send me
	new entity'.		the entire new entity'.
	If-Range = "If-Range" ":" ( entity-tag | HTTP-date )		If-Range = "If-Range" ":" OWS If-Range-v
			If-Range-v = entity-tag / HTTP-date
	If the client has no entity tag for an entity, but does have a Last-		If the client has no entity tag for an entity, but does have a Last-
	Modified date, it MAY use that date in an If-Range header. (The		Modified date, it MAY use that date in an If-Range header. (The
	server can distinguish between a valid HTTP-date and any form of		server can distinguish between a valid HTTP-date and any form of
	entity-tag by examining no more than two characters.) The If-Range		entity-tag by examining no more than two characters.) The If-Range
	header SHOULD only be used together with a Range header, and MUST be		header SHOULD only be used together with a Range header, and MUST be
	ignored if the request does not include a Range header, or if the		ignored if the request does not include a Range header, or if the
	server does not support the sub-range operation.		server does not support the sub-range operation.
	If the entity tag given in the If-Range header matches the current		If the entity tag given in the If-Range header matches the current
	skipping to change at page 11, line 15		skipping to change at page 11, line 20
	range operations.)		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 entity-body (not necessarily the same as the message-body).		the entity-body (not necessarily the same as the message-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 entity.		of ranges within a single entity.
	ranges-specifier = byte-ranges-specifier		ranges-specifier = byte-ranges-specifier
	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
	The first-byte-pos value in a byte-range-spec gives the byte-offset		The first-byte-pos value in a byte-range-spec gives the byte-offset
	of the first byte in a range. The last-byte-pos value gives the		of the first byte in a range. The last-byte-pos value gives the
	byte-offset of the last byte in the range; that is, the byte		byte-offset of the last byte in the range; that is, the byte
	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
	skipping to change at page 12, line 38		skipping to change at page 12, line 42
	bytes=500-600,601-999		bytes=500-600,601-999
	bytes=500-700,601-999		bytes=500-700,601-999
	6.4.2. Range Retrieval Requests		6.4.2. Range Retrieval Requests
	HTTP retrieval requests using conditional or unconditional GET		HTTP retrieval requests using conditional or unconditional GET
	methods MAY request one or more sub-ranges of the entity, instead of		methods MAY request one or more sub-ranges of the entity, instead of
	the entire entity, using the Range request header, which applies to		the entire entity, using the Range request header, which applies to
	the entity returned as the result of the request:		the entity returned as the result of the request:
	Range = "Range" ":" ranges-specifier		Range = "Range" ":" OWS Range-v
			Range-v = ranges-specifier
	A server MAY ignore the Range header. However, HTTP/1.1 origin		A server MAY ignore the Range header. However, HTTP/1.1 origin
	servers and intermediate caches ought to support byte ranges when		servers and intermediate caches ought to support byte ranges when
	possible, since Range supports efficient recovery from partially		possible, since Range supports efficient recovery from partially
	failed transfers, and supports efficient partial retrieval of large		failed transfers, and supports efficient partial retrieval of large
	entities.		entities.
	If the server supports the Range header and the specified range or		If the server supports the Range header and the specified range or
	ranges are appropriate for the entity:		ranges are appropriate for the entity:
	skipping to change at page 14, line 21		skipping to change at page 14, line 21
	Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi		Larry Masinter, Jeff Mogul, Lou Montulli, David W. Morris, Luigi
	Rizzo, and Bill Weihl.		Rizzo, and Bill Weihl.
	10. References		10. References
	10.1. Normative References		10.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-04		and Message Parsing", draft-ietf-httpbis-p1-messaging-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part3] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload		and J. Reschke, Ed., "HTTP/1.1, part 3: Message Payload
	and Content Negotiation", draft-ietf-httpbis-p3-payload-04		and Content Negotiation", draft-ietf-httpbis-p3-payload-05
	(work in progress), August 2008.		(work in progress), November 2008.
	[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-04 (work in		Requests", draft-ietf-httpbis-p4-conditional-05 (work in
	progress), August 2008.		progress), November 2008.
	[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,		[Part6] Fielding, R., Ed., Gettys, J., Mogul, J., Frystyk, H.,
	Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,		Masinter, L., Leach, P., Berners-Lee, T., Lafon, Y., Ed.,
	and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",		and J. Reschke, Ed., "HTTP/1.1, part 6: Caching",
	draft-ietf-httpbis-p6-cache-04 (work in progress),		draft-ietf-httpbis-p6-cache-05 (work in progress),
	August 2008.		November 2008.
	[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.
	10.2. Informative References		10.2. Informative References
	skipping to change at page 15, line 23		skipping to change at page 15, line 23
	September 2004.		September 2004.
	[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and		[RFC4288] Freed, N. and J. Klensin, "Media Type Specifications and
	Registration Procedures", BCP 13, RFC 4288, December 2005.		Registration Procedures", BCP 13, RFC 4288, December 2005.
	Appendix A. Internet Media Type multipart/byteranges		Appendix A. Internet Media Type multipart/byteranges
	When an HTTP 206 (Partial Content) response message includes the		When an HTTP 206 (Partial Content) response message includes the
	content of multiple ranges (a response to a request for multiple non-		content of multiple ranges (a response to a request for multiple non-
	overlapping ranges), these are transmitted as a multipart message-		overlapping ranges), these are transmitted as a multipart message-
	body [RFC2046]. The media type for this purpose is called		body ([RFC2046], Section 5.1). The media type for this purpose is
	"multipart/byteranges". The following is to be registered with IANA		called "multipart/byteranges". The following is to be registered
	[RFC4288].		with IANA [RFC4288].
	The multipart/byteranges media type includes two or more parts, each		The multipart/byteranges media type includes one or more parts, each
	with its own Content-Type and Content-Range fields. The required		with its own Content-Type and Content-Range fields. The required
	boundary parameter specifies the boundary string used to separate		boundary parameter specifies the boundary string used to separate
	each body-part.		each body-part.
	Type name: multipart		Type name: multipart
	Subtype name: byteranges		Subtype name: byteranges
	Required parameters: boundary		Required parameters: boundary
	skipping to change at page 17, line 42		skipping to change at page 17, line 42
	syntactic problems, and range doesn't exist in the document. The 416		syntactic problems, and range doesn't exist in the document. The 416
	status code was needed to resolve this ambiguity needed to indicate		status code was needed to resolve this ambiguity needed to indicate
	an error for a byte range request that falls outside of the actual		an error for a byte range request that falls outside of the actual
	contents of a document. (Section 4.2, 6.2)		contents of a document. (Section 4.2, 6.2)
	B.2. Changes from RFC 2616		B.2. Changes from RFC 2616
	Clarify that it is not ok to use a weak cache validator in a 206		Clarify that it is not ok to use a weak cache validator in a 206
	response. (Section 4.1)		response. (Section 4.1)
			Clarify that multipart/byteranges can consist of a single part.
			(Appendix A)
	Appendix C. Change Log (to be removed by RFC Editor before publication)		Appendix C. Change Log (to be removed by RFC Editor before publication)
	C.1. Since RFC2616		C.1. Since RFC2616
	Extracted relevant partitions from [RFC2616].		Extracted relevant partitions from [RFC2616].
	C.2. Since draft-ietf-httpbis-p5-range-00		C.2. Since draft-ietf-httpbis-p5-range-00
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache		o <http://tools.ietf.org/wg/httpbis/trac/ticket/18>: "Cache
	validators in 206 responses"		validators in 206 responses"
	(<http://purl.org/NET/http-errata#ifrange206>)		(<http://purl.org/NET/http-errata#ifrange206>)
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative		o <http://tools.ietf.org/wg/httpbis/trac/ticket/35>: "Normative and
	and Informative references"		Informative references"
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative		o <http://tools.ietf.org/wg/httpbis/trac/ticket/86>: "Normative up-
	up-to-date references"		to-date references"
	C.3. Since draft-ietf-httpbis-p5-range-01		C.3. Since draft-ietf-httpbis-p5-range-01
	Closed issues:		Closed issues:
	o <http://www3.tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating		o <http://tools.ietf.org/wg/httpbis/trac/ticket/55>: "Updating to
	to RFC4288"		RFC4288"
	Ongoing work on ABNF conversion		Ongoing work on ABNF conversion
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/36>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
	o Add explicit references to BNF syntax and rules imported from		o Add explicit references to BNF syntax and rules imported from
	other parts of the specification.		other parts of the specification.
	C.4. Since draft-ietf-httpbis-p5-range-02		C.4. Since draft-ietf-httpbis-p5-range-02
	Ongoing work on IANA Message Header Registration		Ongoing work on IANA Message Header Registration
	(<http://www3.tools.ietf.org/wg/httpbis/trac/ticket/40>):		(<http://tools.ietf.org/wg/httpbis/trac/ticket/40>):
	o Reference RFC 3984, and update header registrations for headers		o Reference RFC 3984, and update header registrations for headers
	defined in this document.		defined in this document.
	C.5. Since draft-ietf-httpbis-p5-range-03		C.5. Since draft-ietf-httpbis-p5-range-03
			C.6. Since draft-ietf-httpbis-p5-range-04
			Closed issues:
			o <http://tools.ietf.org/wg/httpbis/trac/ticket/133>: "multipart/
			byteranges minimum number of parts"
			Ongoing work on ABNF conversion
			(<http://tools.ietf.org/wg/httpbis/trac/ticket/36>):
			o Use "/" instead of "|" for alternatives.
			o Introduce new ABNF rules for "bad" whitespace ("BWS"), optional
			whitespace ("OWS") and required whitespace ("RWS").
			o Rewrite ABNFs to spell out whitespace rules, factor out header
			value format definitions.
	Index		Index
	2		2
	206 Partial Content (status code) 5		206 Partial Content (status code) 5
	4		4
	416 Requested Range Not Satisfiable (status code) 6		416 Requested Range Not Satisfiable (status code) 6
	A		A
	Accept-Ranges header 7		Accept-Ranges header 7
	skipping to change at page 19, line 4		skipping to change at page 19, line 23
	Index		Index
	2		2
	206 Partial Content (status code) 5		206 Partial Content (status code) 5
	4		4
	416 Requested Range Not Satisfiable (status code) 6		416 Requested Range Not Satisfiable (status code) 6
	A		A
	Accept-Ranges header 7		Accept-Ranges header 7
	C		C
	Content-Range header 8		Content-Range header 8
	G		G
	Grammar		Grammar
	Accept-Ranges 7		Accept-Ranges 7
			Accept-Ranges-v 7
	acceptable-ranges 7		acceptable-ranges 7
	byte-content-range-spec 8		byte-content-range-spec 8
	byte-range-resp-spec 8		byte-range-resp-spec 8
	byte-range-set 11		byte-range-set 11
	byte-range-spec 11		byte-range-spec 11
	byte-ranges-specifier 11		byte-ranges-specifier 11
	bytes-unit 5		bytes-unit 5
	Content-Range 8		Content-Range 8
	content-range-spec 8		content-range-spec 8
			Content-Range-v 8
	first-byte-pos 11		first-byte-pos 11
	If-Range 10		If-Range 10
			If-Range-v 10
	instance-length 8		instance-length 8
	last-byte-pos 11		last-byte-pos 11
	other-range-unit 5		other-range-unit 5
	Range 12		Range 12
	range-unit 5		range-unit 5
			Range-v 12
	ranges-specifier 11		ranges-specifier 11
	suffix-byte-range-spec 11		suffix-byte-range-spec 11
	suffix-length 11		suffix-length 11
	H		H
	Headers		Headers
	Accept-Ranges 7		Accept-Ranges 7
	Content-Range 8		Content-Range 8
	If-Range 10		If-Range 10
	Range 10		Range 10
End of changes. 43 change blocks.
	51 lines changed or deleted		81 lines changed or added
This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/