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

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.

Received on Tuesday, 8 May 2012 20:37:52 UTC