
INTRODUCTION, paragraph 1:
OLD:

 HTTPbis Working Group                                   R. Fielding, Ed.
 Internet-Draft                                                     Adobe
 Obsoletes: 2616 (if approved)                              Y. Lafon, Ed.
 Intended status: Standards Track                                     W3C
 Expires: December 8, 2014                                J. Reschke, Ed.
                                                               greenbytes
                                                             June 6, 2014

NEW:

 Internet Engineering Task Force (IETF)                  R. Fielding, Ed.
 Request for Comments: 7233                                         Adobe
 Obsoletes: 2616                                            Y. Lafon, Ed.
 Category: Standards Track                                            W3C
 ISSN: 2070-1721                                          J. Reschke, Ed.
                                                               greenbytes
                                                               June 2014


INTRODUCTION, paragraph 2:
OLD:

          Hypertext Transfer Protocol (HTTP/1.1): Range Requests
                    draft-ietf-httpbis-p5-range-latest

NEW:

          Hypertext Transfer Protocol (HTTP/1.1): Range Requests


INTRODUCTION, paragraph 5:
OLD:

 Editorial Note (To be removed by RFC Editor)
 
    Discussion of this draft takes place on the HTTPBIS working group
    mailing list (ietf-http-wg@w3.org), which is archived at
    <http://lists.w3.org/Archives/Public/ietf-http-wg/>.
 
    The current issues list is at
    <http://tools.ietf.org/wg/httpbis/trac/report/3> and related
    documents (including fancy diffs) can be found at
    <http://tools.ietf.org/wg/httpbis/>.
 
    _This is a temporary document for the purpose of tracking the
    editorial changes made during the AUTH48 (RFC publication) phase._
 
 Status of This Memo

NEW:

 Status of This Memo


INTRODUCTION, paragraph 6:
OLD:

    This Internet-Draft is submitted in full conformance with the
    provisions of BCP 78 and BCP 79.

NEW:

    This is an Internet Standards Track document.


INTRODUCTION, paragraph 7:
OLD:

    Internet-Drafts are working documents of the Internet Engineering
    Task Force (IETF).  Note that other groups may also distribute
    working documents as Internet-Drafts.  The list of current Internet-
    Drafts is at http://datatracker.ietf.org/drafts/current/.

NEW:

    This document is a product of the Internet Engineering Task Force
    (IETF).  It represents the consensus of the IETF community.  It has
    received public review and has been approved for publication by the
    Internet Engineering Steering Group (IESG).  Further information on
    Internet Standards is available in Section 2 of RFC 5741.


INTRODUCTION, paragraph 8:
OLD:

    Internet-Drafts are draft documents valid for a maximum of six months
    and may be updated, replaced, or obsoleted by other documents at any
    time.  It is inappropriate to use Internet-Drafts as reference
    material or to cite them other than as "work in progress."
    This Internet-Draft will expire on December 8, 2014.

NEW:

    Information about the current status of this document, any errata,
    and how to provide feedback on it may be obtained at
    http://www.rfc-editor.org/info/rfc7233.


INTRODUCTION, paragraph 14:
OLD:

    1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
      1.1.  Conformance and Error Handling . . . . . . . . . . . . . .  4
      1.2.  Syntax Notation  . . . . . . . . . . . . . . . . . . . . .  4
    2.  Range Units  . . . . . . . . . . . . . . . . . . . . . . . . .  4
      2.1.  Byte Ranges  . . . . . . . . . . . . . . . . . . . . . . .  5
      2.2.  Other Range Units  . . . . . . . . . . . . . . . . . . . .  7
      2.3.  Accept-Ranges  . . . . . . . . . . . . . . . . . . . . . .  7
    3.  Range Requests . . . . . . . . . . . . . . . . . . . . . . . .  7
      3.1.  Range  . . . . . . . . . . . . . . . . . . . . . . . . . .  7
      3.2.  If-Range . . . . . . . . . . . . . . . . . . . . . . . . .  9
    4.  Responses to a Range Request . . . . . . . . . . . . . . . . . 10
      4.1.  206 Partial Content  . . . . . . . . . . . . . . . . . . . 10
      4.2.  Content-Range  . . . . . . . . . . . . . . . . . . . . . . 12
      4.3.  Combining Ranges . . . . . . . . . . . . . . . . . . . . . 14
      4.4.  416 Range Not Satisfiable  . . . . . . . . . . . . . . . . 15
    5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
      5.1.  Range Unit Registry  . . . . . . . . . . . . . . . . . . . 15
        5.1.1.  Procedure  . . . . . . . . . . . . . . . . . . . . . . 15
        5.1.2.  Registrations  . . . . . . . . . . . . . . . . . . . . 16
      5.2.  Status Code Registration . . . . . . . . . . . . . . . . . 16
      5.3.  Header Field Registration  . . . . . . . . . . . . . . . . 16
      5.4.  Internet Media Type Registration . . . . . . . . . . . . . 17
        5.4.1.  Internet Media Type multipart/byteranges . . . . . . . 17
    6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
      6.1.  Denial-of-Service Attacks Using Range  . . . . . . . . . . 18
    7.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 18
    8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
      8.1.  Normative References . . . . . . . . . . . . . . . . . . . 19
      8.2.  Informative References . . . . . . . . . . . . . . . . . . 19
    Appendix A.  Internet Media Type multipart/byteranges  . . . . . . 20
    Appendix B.  Changes from RFC 2616 . . . . . . . . . . . . . . . . 21
    Appendix C.  Imported ABNF . . . . . . . . . . . . . . . . . . . . 21
    Appendix D.  Collected ABNF  . . . . . . . . . . . . . . . . . . . 21
    Index  . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

NEW:

    1. Introduction ....................................................4
       1.1. Conformance and Error Handling .............................4
       1.2. Syntax Notation ............................................4
    2. Range Units .....................................................5
       2.1. Byte Ranges ................................................5
       2.2. Other Range Units ..........................................7
       2.3. Accept-Ranges ..............................................7
    3. Range Requests ..................................................8
       3.1. Range ......................................................8
       3.2. If-Range ...................................................9
    4. Responses to a Range Request ...................................10
       4.1. 206 Partial Content .......................................10
       4.2. Content-Range .............................................12
       4.3. Combining Ranges ..........................................14
       4.4. 416 Range Not Satisfiable .................................15
    5. IANA Considerations ............................................16
       5.1. Range Unit Registry .......................................16
            5.1.1. Procedure ..........................................16
            5.1.2. Registrations ......................................16
       5.2. Status Code Registration ..................................17
       5.3. Header Field Registration .................................17
       5.4. Internet Media Type Registration ..........................17
            5.4.1. Internet Media Type multipart/byteranges ...........18
    6. Security Considerations ........................................19
       6.1. Denial-of-Service Attacks Using Range .....................19
    7. Acknowledgments ................................................19
    8. References .....................................................20
       8.1. Normative References ......................................20
       8.2. Informative References ....................................20
    Appendix A. Internet Media Type multipart/byteranges ..............21
    Appendix B. Changes from RFC 2616 .................................22
    Appendix C. Imported ABNF .........................................22
    Appendix D. Collected ABNF ........................................23
    Index .............................................................24


Section 2.1., paragraph 15:
OLD:

    If the selected representation is shorter than the specified suffix-
    length, the entire representation is used.

NEW:

    If the selected representation is shorter than the specified
    suffix-length, the entire representation is used.


Section 2.1., paragraph 25:
OLD:

    If a valid byte-range-set includes at least one byte-range-spec with
    a first-byte-pos that is less than the current length of the
    representation, or at least one suffix-byte-range-spec with a non-
    zero suffix-length, then the byte-range-set is satisfiable.
    Otherwise, the byte-range-set is unsatisfiable.

NEW:

    If a valid byte-range-set includes at least one byte-range-spec with
    a first-byte-pos that is less than the current length of the
    representation, or at least one suffix-byte-range-spec with a
    non-zero suffix-length, then the byte-range-set is satisfiable.
    Otherwise, the byte-range-set is unsatisfiable.


Section 2.1., paragraph 26:
OLD:

    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 MUST
    anticipate potentially large decimal numerals and prevent parsing
    errors due to integer conversion overflows.

NEW:

    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 MUST
    anticipate potentially large decimal numerals and prevent parsing
    errors due to integer conversion overflows.


Section 3.2., paragraph 4:
OLD:

    A client MUST NOT generate an If-Range header field in a request that
    does not contain a Range header field.  A server MUST ignore an If-
    Range header field received in a request that does not contain a
    Range header field.  An origin server MUST ignore an If-Range header
    field received in a request for a target resource that does not
    support Range requests.

NEW:

    A client MUST NOT generate an If-Range header field in a request that
    does not contain a Range header field.  A server MUST ignore an
    If-Range header field received in a request that does not contain a
    Range header field.  An origin server MUST ignore an If-Range header
    field received in a request for a target resource that does not
    support Range requests.


Section 3.2., paragraph 5:
OLD:

    A client MUST NOT generate an If-Range header field containing an
    entity-tag that is marked as weak.  A client MUST NOT generate an If-
    Range header field containing an HTTP-date unless the client has no
    entity-tag for the corresponding representation and the date is a
    strong validator in the sense defined by Section 2.2.2 of [RFC7232].

NEW:

    A client MUST NOT generate an If-Range header field containing an
    entity-tag that is marked as weak.  A client MUST NOT generate an
    If-Range header field containing an HTTP-date unless the client has
    no entity-tag for the corresponding representation and the date is a
    strong validator in the sense defined by Section 2.2.2 of [RFC7232].


Section 3.2., paragraph 7:
OLD:

    If the validator given in the If-Range header field matches the
    current validator for the selected representation of the target
    resource, then the server SHOULD process the Range header field as
    requested.  If the validator does not match, the server MUST ignore
    the Range header field.  Note that this comparison by exact match,
    including when the validator is an HTTP-date, differs from the
    "earlier than or equal to" comparison used when evaluating an If-
    Unmodified-Since conditional.

NEW:

    If the validator given in the If-Range header field matches the
    current validator for the selected representation of the target
    resource, then the server SHOULD process the Range header field as
    requested.  If the validator does not match, the server MUST ignore
    the Range header field.  Note that this comparison by exact match,
    including when the validator is an HTTP-date, differs from the
    "earlier than or equal to" comparison used when evaluating an
    If-Unmodified-Since conditional.


Section 206, paragraph 8:
OLD:

    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.  A client that receives a multipart response MUST
    inspect the Content-Range header field present in each body part in
    order to determine which range is contained in that body part; a
    client cannot rely on receiving the same ranges that it requested,
    nor the same order that it requested.

NEW:

    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.  A client that receives a multipart
    response MUST inspect the Content-Range header field present in each
    body part in order to determine which range is contained in that body
    part; a client cannot rely on receiving the same ranges that it
    requested, nor the same order that it requested.


Section 4.2., paragraph 13:
OLD:

    A Content-Range field value is invalid if it contains a byte-range-
    resp that has a last-byte-pos value less than its first-byte-pos
    value, or a complete-length value less than or equal to its last-
    byte-pos value.  The recipient of an invalid Content-Range MUST NOT
    attempt to recombine the received content with a stored
    representation.

NEW:

    A Content-Range field value is invalid if it contains a
    byte-range-resp that has a last-byte-pos value less than its
    first-byte-pos value, or a complete-length value less than or equal
    to its last-byte-pos value.  The recipient of an invalid
    Content-Range MUST NOT attempt to recombine the received content with
    a stored representation.


Section 4.2., paragraph 14:
OLD:

    A server generating a 416 (Range Not Satisfiable) response to a byte-
    range request SHOULD send a Content-Range header field with an
    unsatisfied-range value, as in the following example:

NEW:

    A server generating a 416 (Range Not Satisfiable) response to a
    byte-range request SHOULD send a Content-Range header field with an
    unsatisfied-range value, as in the following example:


Section 5.1.1., paragraph 3:
OLD:

    o  Description
    o  Pointer to specification text

NEW:

    o  Description
 
    o  Pointer to specification text


Section 8.1., paragraph 0:
OLD:

 8.  References
 8.1.  Normative References

NEW:

 8.  References
 
 8.1.  Normative References


Section 8.1., paragraph 4:
OLD:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               draft-ietf-httpbis-p1-messaging-latest (work in progress),
               June 2014.

NEW:

    [RFC7230]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Message Syntax and Routing",
               RFC 7230, June 2014.


Section 8.1., paragraph 5:
OLD:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content",
               draft-ietf-httpbis-p2-semantics-latest (work in progress),
               June 2014.

NEW:

    [RFC7231]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Semantics and Content", RFC 7231,
               June 2014.


Section 8.1., paragraph 6:
OLD:

    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Conditional Requests",
               draft-ietf-httpbis-p4-conditional-latest (work in
               progress), June 2014.

NEW:

    [RFC7232]  Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer
               Protocol (HTTP/1.1): Conditional Requests", RFC 7232,
               June 2014.


Section 8.1., paragraph 7:
OLD:

    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
               draft-ietf-httpbis-p6-cache-latest (work in progress),
               June 2014.

NEW:

    [RFC7234]  Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke,
               Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching",
               RFC 7234, June 2014.


Appendix C., paragraph 2:
OLD:

    Note that all rules derived from token are to be compared case-
    insensitively, like range-unit and acceptable-ranges.

NEW:

    Note that all rules derived from token are to be compared
    case-insensitively, like range-unit and acceptable-ranges.


Section 1.2, paragraph 23:
OLD:

    G
       Grammar
          Accept-Ranges  7
          acceptable-ranges  7
          byte-content-range  12
          byte-range  12
          byte-range-resp  12
          byte-range-set  5
          byte-range-spec  5
          byte-ranges-specifier  5
          bytes-unit  5
          complete-length  12
          Content-Range  12
          first-byte-pos  5
          If-Range  9
          last-byte-pos  5
          other-content-range  12
          other-range-resp  12
          other-range-unit  5, 7
          Range  7
          range-unit  5
          ranges-specifier  5
          suffix-byte-range-spec  6
          suffix-length  6
          unsatisfied-range  12

NEW:

    G
       Grammar
          Accept-Ranges  7
          acceptable-ranges  7
          byte-content-range  12
          byte-range  12
          byte-range-resp  12
          byte-range-set  5
          byte-range-spec  5
          byte-ranges-specifier  5
          bytes-unit  5
          complete-length  12
          Content-Range  12
          first-byte-pos  5
          If-Range  9
          last-byte-pos  5
          other-content-range  12
          other-range-resp  12
          other-range-unit  5, 7
          Range  8
          range-unit  5
          ranges-specifier  5
          suffix-byte-range-spec  6
          suffix-length  6
          unsatisfied-range  12


Section 1.2, paragraph 25:
OLD:

    M
       Media Type
          multipart/byteranges  17, 20
          multipart/x-byteranges  20
       multipart/byteranges Media Type  17, 20
       multipart/x-byteranges Media Type  20

NEW:

    M
       Media Type
          multipart/byteranges  18, 21
          multipart/x-byteranges  19
       multipart/byteranges Media Type  18, 21
       multipart/x-byteranges Media Type  21


Section 1.2, paragraph 26:
OLD:

    R
       Range header field  7

NEW:

    R
       Range header field  8

