Hypertext Transfer Protocol (HTTP/1.1): Conditional Requests
draft-ietf-httpbis-p4-conditional-26

[Ballot comment]
Meral Shirazipour raised some editorial comments in the Gen-ART review. I thought that the examples comment was a valid one, for instance. But I have not seen a response. Did the authors consider the comments?

(Of course, not all comments may result in changes. For instance, the issues of splitting or merging the documents are in my opinion something that is difficult to deal with at this stage, and I understand the WG if they do not want to make changes. Assuming all relevant text is still somewhere and reachable through references, of course.)

[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.

IESG/Authors/WG Chairs:

IANA has reviewed draft-ietf-httpbis-p4-conditional-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 two actions which IANA must complete. The second action must be approved by the designated expert for Permanent Message Header Field Names.

First, in the HTTP Status Code Registry at

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

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

+-------+---------------------+-------------+
| Value | Description        | Reference  |
+-------+---------------------+-------------+
| 304  | Not Modified        |[ RFC-to-be ]|
| 412  | Precondition Failed |[ RFC-to-be ]|
+-------+---------------------+-------------+

Second, in the Permanent Message Header Field Names registry in the Message Headers page at

http://www.iana.org/assignments/message-headers/

the following message headers will be updated to reflect the new information provided below:

+---------------------+----------+----------+-------------+
| Header Field Name  | Protocol | Status  | Reference  |
+---------------------+----------+----------+-------------+
| ETag                | http    | standard |[ RFC-to-be ]|
| If-Match            | http    | standard |[ RFC-to-be ]|
| If-Modified-Since  | http    | standard |[ RFC-to-be ]|
| If-None-Match      | http    | standard |[ RFC-to-be ]|
| If-Unmodified-Since | http    | standard |[ RFC-to-be ]|
| Last-Modified      | http    | standard |[ RFC-to-be ]|
+---------------------+----------+----------+-------------+

IANA understands that these are the only actions 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): Conditional 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): Conditional 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 HTTP/1.1 conditional requests,
  including metadata header fields for indicating state changes,
  request header fields for making preconditions on such state, and
  rules for constructing the responses to a conditional request when
  one or more preconditions evaluate to false.


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-p4-conditional/

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

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

1. Summary

Document: draft-ietf-httpbis-p4-conditional-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 HTTP/1.1 conditional requests, including metadata header fields for
indicating state changes, request header fields for making preconditions on
such state, and rules for constructing the responses to a conditional request
when one or more preconditions evaluate to false.

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: None.

Updated registries: None.