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

[Ballot comment]
*) I'll not repeats the OWS discuss point from p1.  If it gets changed there I assume it will get changed here.  If not then this can be ignored.

0) Abstract: Maybe would add stateless in front of protocol in the description.

1) s2.1: might be good to have the ABNF match the text;

The last-byte-pos value gives the
  byte-offset of the last byte, which is OPTIONAL, in the range; that is, the byte
  positions specified are inclusive.

2) s5.4.1: Please add a pointer to the sec cons of this draft instead of "none".

[Ballot comment]
COMMENT 1:
In Section 3.2: It would be helpful to clarify that the interpretation of the date in an If-Range header is effectively the same as with If-Unmodified-Since.

NEW: "When an HTTP-date value is present in an If-Range header field, the precondition verified by the server is that the representation has not changed since that date (as with the If-Unmodified-Since)."


COMMENT 2:
In Section 6.1: This may be outlandish, but is it possible that in some cases, requesting bytes past the end of a file might cause a buffer overflow or similar?

[Ballot comment]

- 3.2: Is an HTTP-date value a valid value for an entity-tag?
If so, I assume that an If-Range value is interpreted as a
date. Do you need to say that?

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-p5-range-24.  Authors should review the comments and/or questions below.  Please report any inaccuracies and respond to any questions as soon as possible.

IANA's reviewer has the following comments/questions:

IANA understands that, upon approval of this document, there are three actions which IANA must complete. The designated expert for Permanent Message Header Field Names must approve the third action.

First, IANA will create a new registry called the HTTP Range Unit Registry at

http://www.iana.org/assignments/http-parameters

The registration rule for this name space is IETF Review as defined in RFC 5226.  Each registration is made up of a name, description, and reference.

There are initial registrations in this new registry as follows:

+-------------+---------------------------------------+-------------+
| Range Unit  | Description                          | Reference  |
| Name        |                                      |            |
+-------------+---------------------------------------+-------------+
| bytes      | a range of octets                    |[ RFC-to-be ]|
| none        | reserved as keyword, indicating no    |{ RFC-to-be ]|
|            | ranges are supported                  |            |
+-------------+---------------------------------------+-------------+

Second, in the HTTP Status Code Registry at

http://www.iana.org/assignments/http-status-codes/

the references for the following entries will be replaced with references to this document:

+-------+-----------------------+-------------+
| Value | Description          | Reference  |
+-------+-----------------------+-------------+
| 206  | Partial Content      |[ RFC-to-be ]|
| 416  | Range Not Satisfiable |[ RFC-to-be ]|
+-------+-----------------------+-------------+

Third, in the Permanent Message Header Field Names registry at
http://www.iana.org/assignments/message-headers

IANA will update these entries as follows:

  +-------------------+----------+----------+-------------+
  | Header Field Name | Protocol | Status  | Reference  |
  +-------------------+----------+----------+-------------+
  | Accept-Ranges    | http    | standard | Section 2.3 |
  | Content-Range    | http    | standard | Section 4.2 |
  | If-Range          | http    | standard | Section 3.2 |
  | Range            | http    | standard | Section 3.1 |
  +-------------------+----------+----------+-------------+

We understand that the authors do not want a "change controller" column added to the registry.

IANA understands that these actions are the only ones required to be completed upon approval of this document.

Note:  The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed.

The following Last Call announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Hypertext Transfer Protocol (HTTP/1.1): Range Requests) to Proposed Standard


The IESG has received a request from the Hypertext Transfer Protocol Bis
WG (httpbis) to consider the following document:
- 'Hypertext Transfer Protocol (HTTP/1.1): Range Requests'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2013-11-04. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The Hypertext Transfer Protocol (HTTP) is an application-level
  protocol for distributed, collaborative, hypertext information
  systems.  This document defines range requests and the rules for
  constructing and combining responses to those requests.


Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p5-range/

Once IESG evaluation begins, IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-httpbis-p5-range/ballot/

No IPR declarations have been submitted directly on this I-D.

1. Summary

Document: draft-ietf-httpbis-p5-range-24
Document Shepherd: Mark Nottingham
Responsible Area Director: Barry Leiba
Publication Type: Proposed Standard

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for
distributed, collaborative, hypertext information systems. This document
defines range requests and the rules for constructing and combining responses
to those requests.

Note that this document is part of a set, which should be reviewed together:

* draft-ietf-httpbis-p1-messaging
* draft-ietf-httpbis-p2-semantics
* draft-ietf-httpbis-p4-conditional
* draft-ietf-httpbis-p5-range
* draft-ietf-httpbis-p6-cache
* draft-ietf-httpbis-p7-auth
* draft-ietf-httpbis-method-registrations
* draft-ietf-httpbis-authscheme-registrations


2. Review and Consensus

As chartered, this work was very constrained; the WG sought only to clarify
RFC2616, making significant technical changes only where there were
considerably interoperability or security issues.

While the bulk of the work was done by a core team of editors, it has been
reviewed by a substantial number of implementers, and design issues enjoyed
input from many of them.

It has been through two Working Group Last Calls, with multiple reviewers each
time. We have also discussed this work with external groups (e.g., the W3C TAG).

3. Intellectual Property

There are no IPR disclosures against this document. The authors have confirmed
that they have no direct, personal knowledge of IPR related to this document
that has not been disclosed.

4. Other Points

Downward references: None.

New registries created:

* The HTTP Range Unit Registry policy is IETF Review. This policy was chosen
  because range units are frequently misunderstood and misapplied.

Updated registries: None.