Comments on cachedraft.txt

Here are some comments on the Jan 22 version of the
http://ftp.digital.com/%7emogul/cachedraft.txt by Jeffrey Mogul.  I'm
writing these as input for the Feb 2 meeting of the caching sub-wg.

I have numbered my comments for easy reference.

(1) I agree with the most of the things said in the Jan 22 versions of
the draft.  I will mainly focus on the things I do not agree with
below.

(2) At the end of the abstract, Jeffrey says that `My intention is
that this document be incorporated into the HTTP/1.1 specification
[1]'.  I don't see how this is going to work.  My main problem with
cachedraft.txt is that it (the finished part of it) is not focused on
making changes in the 1.1 draft.  Rather, it tries to collect as much
background information as possible, and sketches, not defines, some
caching schemes that could work.

I see an in-depth discussion of the details of descriptions of
background information (as found in cachedraft.txt) as an
inappropriate activity for the caching working group, because this
activity will leave less time, of the limited time that is available,
for an in-depth discussion of the details of the protocol definitions
for the 1.1 draft.

(3) Section 2.2, top of page 4: The one restriction on history
mechanisms that _must_ be in 1.1 is that the implementations of these
mechanisms should not generate (too much) requests when the user backs
up into historic information that is stale.
http://www.amazon.com/expires-report.html discussed why this
restriction is needed.

(4) Section 2.3: if the `if and only if' in the definition were
replaced by a plain 'if', I would be much more happy with this
section.

(5) Section 2.6, `major fault' description number 2.: the claim that
servers are forced to keep modification times is incorrect, as servers
are allowed no to send a Last-modified header.

(6) Section 2.6: I like opaque cache validators, but I would say that
a server MAY return them, not SHOULD return them.

(7) Section 2.8: what about restarting an interrupted inline image
request by doing a byte range GET on the part of the image not
recieved earlier?

(8) Section 2.9: I like Expires headers, but I would say that a server
MAY return them, not SHOULD return them.

(9) Section 2.11: The 198 code is just plain silly (Which law?).  As
for the 199 code: how is a proxy supposed to take a non-automatic
action?

(10) Section 2.15: I still disagree with the given interpretation of
section 14.2 of the 1.1 draft.

(11) Section 2.15: The MUST NOT rule about URIs containing `?' is much
to strong: I would only suggest this as a heuristic.

(12) Section 2.15, last sentence: This claim is incorrect.  HTTP 1.0
responses generated in the same second may always be different, this
is an underlying assumption in HTTP that holds for all resources.

(13) Section 3.4: add max-age to the response directives.  It it very
nice to have, because it is much easier to generate than an Expires
header with a correctly formatted date.  See also the `it may be a
better idea to....' paragraph in Section 2.10 near the end of page 15.

Koen.

Received on Friday, 2 February 1996 00:07:05 UTC