I have been selected as the Applications Area Directorate reviewer 
for this draft (for background on APPSDIR, please see 
http://trac.tools.ietf.org/area/app/trac/wiki/ApplicationsAreaDirectorate ).

Please resolve these comments along with any other Last Call comments 
you may receive. Please wait for direction from your document 
shepherd or AD before posting a new version of the draft.

Document: draft-ietf-httpbis-p5-range-24
Title: Hypertext Transfer Protocol (HTTP/1.1): Range Requests
Reviewer: S. Moonesamy
Review Date: October 29, 2013
IETF Last Call Date: October 21, 2013

Summary: This draft requires further review.

This document defines HTTP/1.1 range requests, partial responses, and 
the multipart/byteranges media type.

This document is well-written.  The Introduction section mentions 
that the byte range feature is an optional feature of HTTP.  This 
feature can be used to, for example, resume the download of a large 
file.  The feature is part of the set of documents for the protocol 
while the feature can be considered as not being part of the base 
protocol.  The Security Consideration sections (see Part 1 and Part 
2) do not discuss about whether the feature can be misused (e.g. 
denial of service).

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.

Regards,
S. Moonesamy