Technical Summary
This document specifies the caching semantics of HTTP messages
and the conformance criteria for HTTP caches. The document
seeks Proposed Standard status as it attempts to obsolete (along with
the other draft-ietf-httpbis drafts) a previous standards track document
(RFC2616) and was developed under the compatibility constraints of the
working group charter.
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
Review and Consensus
Many of the experts in HTTP caching, representing some of the most
widely used implementations, were active participants in the working
group. Most of the discussions involved this core group of people, with
additional reviews and contributions by other experienced practitioners
and developers.
Discussion was relatively moderate, with the number of issues raised
being in the middle of the pack of the set of httpbis documents. The
participants in the discussions tended to be the same core of caching
experts, though with other experts in related topics, or those with
valuable experience to share, commonly contributing. External reviews
were not abundant, but due to the highly specific skill set required for
a full review, and the fact that many of the people in industry with
that skill set were participants in the working group, this shouldn't be
considered either surprising or a problem.
Only a small proportion of the issues required a prolonged discussion,
but in each case, consensus was reached through reasoned arguments
grounded in implementation experience using proposed text. I recall no
case where consensus could even be considered "rough", as discussions
were held back not primarily by strong disagreement, but by factors such
as detailed wordsmithing of complex descriptions, or a lack of
information with which a decision could be made (commonly, information
about deployed implementation behaviour, or some aspect of the history
of the protocol's development which needed to be unearthed). Issue
486[1] is a recent example of how some of the more complex discussions
went.
[1] http://lists.w3.org/Archives/Public/ietf-http-wg/2013JulSep/thread.html#msg1040
Personnel
Document Shepherd: Mark Baker
Responsible Area Director: Barry Leiba
RFC Editor Note
Please update the reference to RFC1305 to point instead to RFC5905