Subject: Review of draft-ietf-httpbis-p5-range-19.txt

From: Alexey Melnikov <[email-masked]>
Date: Tue, 08 May 2012 21:02:05 +0100

Hi,
Another late review:

3.1.  206 Partial Content

    The server has fulfilled the partial GET request for the resource.
    The request MUST have included a Range header field (Section 5.4)
    indicating the desired range, and MAY have included an If-Range
    header field (Section 5.3) to make the request conditional.

    The response MUST include the following header fields:

    o  Either a Content-Range header field (Section 5.2) indicating the
       range included with this response, or a multipart/byteranges
       Content-Type including Content-Range fields for each part.  If a
       Content-Length header field is present in the response, its value
       MUST match the actual number of octets transmitted in the message
       body.

Sorry for being dense, but did you mean the specific range or the whole 
original message body?

      Accept-Ranges: none

Maybe "none" should also be registered in the associated IANA registry?

5.2.  Content-Range

      byte-range-resp-spec    = (first-byte-pos "-" last-byte-pos)
                              / "*"

      instance-length         = 1*DIGIT

Are leading zeroes allowed? (I.e. would an implementation that just 
treat these values as strings be Ok?) But more importantly:
  Is there a maximum limit on this value? Is 128bit unsigned value Ok?
  Is there a minimum size any implementation need to support? Is 8bit Ok?

5.4.1.  Byte Ranges

      first-byte-pos  = 1*DIGIT
      last-byte-pos   = 1*DIGIT

As above.

      suffix-length = 1*DIGIT

As above.

Appendix A.  Internet Media Type multipart/byteranges

    The multipart/byteranges media type includes one or more parts, each
    with its own Content-Type and Content-Range fields.  The required
    boundary parameter specifies the boundary string used to separate
    each body-part.

I think the last sentence should be in the template (below).

    Type name:  multipart

    Subtype name:  byteranges

    Required parameters:  boundary

    Optional parameters:  none

    Encoding considerations:  only "7bit", "8bit", or "binary" are
       permitted

    Security considerations:  none

I don't think this is a valid answer here. Either think about security 
issues and add some text here, or replace this with "security 
considerations were not assessed" (or similar).

I suspect Appendix D contains more useful changes than Appendix B.
E.g. new IANA registries should be mentioned.

---

From: Amos Jeffries <[email-masked]>
Date: Wed, 09 May 2012 13:19:51 +1200

> Another late review:

<snip>

>  Is there a minimum size any implementation need to support? Is 8bit 

That is implementation specific detail. Pick your limit and if the 
range value exceeds it they could still be perfectly valid, just relay 
without local handling. HTTP does not have to impose any restrictions 
here.

For example, there are range requests floating around the Internet for 
TB and PB sized objects. But systems with local 32-bit limits are still 
able to relay them when implemented correctly.

AYJ