APPSDIR review of draft-ietf-httpbis-p5-range-24

[mnot]

Major Issues:

---

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

~~There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:~~

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

~~My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html

---

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

---

In Section 2.1:

~~"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):~~

     ~~bytes=500-600,601-999
     bytes=500-700,601-999"~~

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

~~I am trying to understand what the server should do when it receives one or several overlapping ranges.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html

---

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

---

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

~~I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?~~

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

~~It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html

---

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

---

Minor Issues:

---

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

~~As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.~~ - see #515

---

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

---

Nits:

---

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

---

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

Reported by julian.reschke@gmx.de, migrated from https://trac.ietf.org/trac/httpbis/ticket/506

[mnot]

julian.reschke@gmx.de changed origin from http://www.w3.org/mid/6.2.5.6.2.20131028101123.0e37a698@elandnews.comMajor Issues: In Section 2.3: 'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.' There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1: "A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations." My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional. In Section 3.2: "HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2. In Section 2.1: "Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive): bytes=500-600,601-999 bytes=500-700,601-999" And Section 3.1: "A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier." I am trying to understand what the server should do when it receives one or several overlapping ranges. In Section 4.1: "If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A" It is unusual to have a RFC 2119 requirement defined in an appendix. "If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part." I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response? "When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range- spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges." It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should". In Appendix A: "The following definition is to be registered with IANA [BCP13]." The request to IANA should be in the IANA Considerations section. Minor Issues: In Section 1: "Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability." As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase. In Section 2.1: "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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows." There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable. Nits: In Section 2.2: "Range units are intended to be extensible." Section 3.12 of RFC 2616 states that: "The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges." I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units. In Section 2.3: "A server that does not support any kind of range request for the target resource resource MAY send" The word "resource" is duplicated. to http://www.w3.org/mid/6.2.5.6.2.20131028101123.0e37a698@elandnews.com

[mnot]

julian.reschke@gmx.de commented:

From 2438:

fix typo (see #506)

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated.

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de commented:

From 2441:

move the multipart/byteranges media type registration into the IANA Considerations section (see #506)

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section.

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix.

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

Minor Issues:

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

Nits:

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

---

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

---

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

---

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

---

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

---

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

---

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

---

Minor Issues:

---

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

---

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

---

Nits:

---

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

---

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

---

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

---

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

---

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

---

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

---

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

---

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

---

Minor Issues:

---

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.

---

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

---

Nits:

---

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

---

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

---

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

---

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

---

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

---

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

---

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

---

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

---

Minor Issues:

---

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

~~As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.~~ - see #515

---

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

---

Nits:

---

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

---

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed description from:

Major Issues:

---

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.

---

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

---

In Section 2.1:

"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):

     bytes=500-600,601-999
     bytes=500-700,601-999"

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

I am trying to understand what the server should do when it receives one or several overlapping ranges.

---

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

---

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".

---

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

---

Minor Issues:

---

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

~~As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.~~ - see #515

---

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

---

Nits:

---

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

---

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

to:

Major Issues:

---

In Section 2.3:

'The "Accept-Ranges" header field allows a server to indicate that it supports range requests for the target resource.'

~~There isn't any recommendation or requirement for the server to send "Accept-Ranges: bytes"; it's a RFC 2119 "may". It seems better if there is a recommendation for the server to advertise the feature if the server supports it. There is the following text in Section 3.1:~~

"A server MAY ignore the Range header field. However, origin servers and intermediate caches ought to support byte ranges when possible, since Range supports efficient recovery from partially failed transfers and partial retrieval of large representations."

~~My understanding of the above is that the server can ignore the Range header field but it is politely recommended that origin servers and intermediate caches support it. This looks like a workaround to avoid introducing a RFC 2119 "should". The text explains why it is worthwhile to support byte ranges while the Introduction sections states that this feature is optional.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html

---

In Section 3.2:

~~"HTTP-date" is defined in the Appendix C. I suggest importing the rules should be in Section 1.2.~~ - see #505

---

In Section 2.1:

~~"Other valid (but not canonical) specifications of the second 500 bytes (byte offsets 500-999, inclusive):~~

     ~~bytes=500-600,601-999
     bytes=500-700,601-999"~~

And Section 3.1:

"A client that is requesting multiple ranges SHOULD list those ranges in ascending order (the order in which they would typically be received in a complete representation) unless there is a specific need to request a later part earlier."

~~I am trying to understand what the server should do when it receives one or several overlapping ranges.~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html

---

In Section 4.1:

"If multiple parts are being transferred, the server generating the 206 response MUST generate a "multipart/byteranges" payload, as defined in Appendix A"

It is unusual to have a RFC 2119 requirement defined in an appendix. - see #505

---

"If the selected representation would have had a Content-Type header field in a 200 (OK) response, the server SHOULD generate that same Content-Type field in the header area of each body part."

~~I don't understand why the RFC 2119 "should" is used in the above. When can the "should" be ignored? Is the server supposed to generate the same Content-Type header field in each header area if the selected representation would have a Content-Type header field for a 200 (OK) response?~~

"When a multipart response payload is generated, the server SHOULD send the parts in the same order that the corresponding byte-range-spec appeared in the received Range header field, excluding those ranges that were deemed unsatisfiable or that were coalesced into other ranges."

~~It is recommended in the Section 3.1 that the client lists the ranges it requests in ascending order. The above text recommends that the server should send the parts in the same order as the request. There can be an interoperability issue when the two sides are told to do RFC 2119 "should".~~ - see http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0384.html

---

In Appendix A:

"The following definition is to be registered with IANA [BCP13]."

The request to IANA should be in the IANA Considerations section. - 2441

---

Minor Issues:

---

In Section 1:

"Range requests are an OPTIONAL feature of HTTP, designed so that recipients not implementing this feature (or not supporting it for the target resource) can respond as if it is a normal GET request without impacting interoperability."

~~As the word "OPTIONAL" in the above is not interpreted according to RFC 2119 I suggest using plain English instead of a word in uppercase.~~ - see #515

---

In Section 2.1:

"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 predefined limit to the length of a payload, recipients ought to anticipate potentially large decimal numerals and prevent parsing errors due to integer conversion overflows."

~~There is a RFC 2119 "should" in Section 3.3.2 of draft-ietf-httpbis-p1-messaging-24 about integer conversion and a reference to Section 9.3 of that draft. I may have missed integer conversation issues in the reviews. I suggest doing a verification to verify that there is adequate text where it is applicable.~~ - see #507

---

Nits:

---

In Section 2.2:

"Range units are intended to be extensible."

Section 3.12 of RFC 2616 states that:

"The only range unit defined by HTTP/1.1 is "bytes". HTTP/1.1 implementations MAY ignore ranges specified using other units. HTTP/1.1 has been designed to allow implementations of applications that do not depend on knowledge of ranges."

~~I consider the creation of the registry as "it does not cost anything to add one more registry". The text from RFC 2616 suggests that the only unit specified is "bytes" and that HTTP/1.1 does not depend upon the knowledge of this optional feature. I don't see any reason to have other range units.~~ - see #85 and reply in http://lists.w3.org/Archives/Public/ietf-http-wg/2013OctDec/0383.html

---

In Section 2.3:

"A server that does not support any kind of range request for the target resource resource MAY send"

The word "resource" is duplicated. - see 2438

[mnot]

julian.reschke@gmx.de changed severity from In WG Last Call to In IETF LC

[mnot]

• julian.reschke@gmx.de changed milestone from unassigned to 25
• julian.reschke@gmx.de changed resolution to incorporated
• julian.reschke@gmx.de changed status from new to closed