1. cache control directives, redux:
    1. extension field is missing. Seems like a mistake to me. Is min-vers needed? Does it hurt? Should it be defined relative to HTTP versions, or some other numbering schemes.
      All agree we should allow for extension directive, per Roy's complaints. We decided after discussion that min-vers would then probably not be needed, and would be removed (and if we needed a mechanism like min-vers later, it could still be added.) Roy to draft wording changes for extension field.
    2. no-transform ill specified; see mail on mailing list for context
      Wording to JG people like, but the discussion made us conclude another cache warning is in order. Jeff to draft changes for this.
    3. must and proxy revalidate
      We understand why these are needed. Paul to draft a few sentences to motivate what appears almost identical functions in the specification.
    4. max-age, should it default to infinity if not specified? Seems like a reasonable thing.
      Max-age by itself will default to infinity. Roy to draft changes.
    5. no-store does not motivate itself as currently written.
      Discussed no-store; agree we need it, but that text needs a bit of work.
  2. If-Modified-Since: should it apply to the entity, or the resource as a whole? Either seems possible. We need to make a decision.
    Concensus is that it should apply to the entity. However, Roy still thinks there may be a edge condition when using IMS where you might get the wrong answer, but without the concrete example, after extensive discussion, no one could understand it. Roy will draft a concrete example and if it is a real problem, we'll address at draft standard. We believe we should go ahead and submit the draft as is to IESG, given our current understanding (or lack thereof of what is an edge case). Implementation experience may clarify this.
  3. related, is the expiration time the minimum of the entities, or does each entity have its own?
    Related to 2.
  4. Date rather than Last-Modified should be used as the cache validator?
    Related to 2.
  5. Robert Thau's comments of today. See W.G. archive.
    Robert has two issues. One is easy, and a few word fix should clarify. The other required extensive discussion, and Jeff Mogul is to draft addition to 304 not modified to make clear what headers should/should not be sent.
  6. Anselm's complaints about Accept BNF being ambiguous. (see W.G. archives, 1:00 today).
    Koen to get to JG the simple change to make this clear.
  7. Accept-Ranges is 04 the correct definition? Roy's argument that Accept-Ranges can be added anywhere in a proxy path looks right to me.
    Lou Montoulli and Roy both think draft 04 is correct as is. Jeff is still slightly worried, but we'll go with it. Correct is defined to be serves the purpose for which it was intended, though if it weren't current practice, we'd have problems with it.
  8. There is a discussion about a problem in ranges (off by one error). What is the least change we can make to fix the problem, if there is one?
    Change has been vetted, and already applied to draft.
  9. 206 response change
    Done, to clarify multipart interactions; already applied to draft.
  10. mxb; should it do back in?
    No, it will be left out.
  11. JG to add back the advice for 1.0 cache compatibility to the appendix; change got dropped on floor from last week.
  12. Discussed discover of Proxy-Connection that netscape does that no-one had seen. We don't have time to do this kind of addition (to relate how it works for interoperability). To proceed, we plan to go ahead and progress the current draft; at Montreal we'll decide if we have to face this one, and consult the IESG process guru's to see if we have to recycle at proposed.
  1. Subject: Re: Reminder: Regularly scheduled teleconference for HTTP-1.1 at 2:00 EST
    To: jg@w3.org
    Date: Thu, 6 Jun 1996 16:35:04 +0200 (MET DST)
    Cc: paulle@microsoft.com, masinter@parc.xerox.com, dmk@allegra.att.com,
    koen@win.tue.nl, frystyk@w3.org, mogul@pa.dec.com,
    fielding@avron.ics.uci.edu, alex.hopmann@resnova.com, ari@netscape.com,
    john@math.nwu.edu, klensin@mail1.reston.mci.net
    Agenda items:

    Note: the MUSTs below only represent my view, of course.

    1 (MUST result in change)
    section 12:

    HTTP/1.1 origin servers MUST include an appropriate Vary header field
    (section 14.43) in any response based on server-driven negotiation.
    insert `cachable'. Same in the Vary section itself.
    Koen to send jg changes.

2 (MUST result in change)
I can't parse the `variant' definition in terminology section.
Suggested new version:

A representation of a resource, which may be updated through time, which is available to a server for inclusion in responses.
Jg to choose among any of the competing definitions, so long as it isn't the current one…
This suggestion does not imply any terminology changes elsewere.

3 (MUST result in change)
no-transform, and section 14.9.5

Suggested change: one of these

1) delete 14.9.5, delete no-transform
2) delete 14.9.5, change no-transform to allow-transform and add note that future specifications might allow caches to transform if this directive is present

also, maybe add a note that compression by a proxy must happen at the transfer-encoding level.

Discussed above, and resolved above.


From: rst@ai.mit.edu (Robert S. Thau)
Date: Thu, 6 Jun 1996 10:42:26 -0400
Message-Id: <199606061442.KAA11830@volterra.ai.mit.edu>
To: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com

Subject: Concerns with draft-04...

Well, I *finally* (belatedly) did a serious review of the draft-04 text. There still may be a few problems... here are two items in particular I picked up (one big item and another which is small, but --- IMHO --- serious).

1) Section 14.7 says that a proxy MUST NOT edit the Allow: header value. Section 9.2 says that it MUST, at least in the specific case of a response to an OPTIONS request. Who's right?

2) The wording in section 10.3.5 on what headers should be sent with a 304 is an improvement, but I still can't figure out what *exactly* a conforming server is supposed to do. The three conditions there are:

a) A response MUST include any values which might differ from those which were received with a prior 200 response.

b) A response MUST include any values that caches use for matching requests and responses with cache entries.

c) A response SHOULD NOT include anything "which cannot possibly have changed."

These criteria don't seem entirely consistent with the examples of "relevant" headers given in the text. For instance, I'm not sure which of criteria (a) or (b) makes "Server" a particularly relevant header, especially given that in almost all cases, (c) will apply. However, it is the rules themselves that are normative, and my main concern is with them.

To begin with, (b) and (c) seem to be partially contradictory --- the implication of (b) seems to be that even if a header that caches use for checking matches to cache entries cannot possibly have changed, the 304 response should include it anyway.

A more serious concern is that I can't figure out how, say, a member of a chain of HTTP/1.1 caches sandwiched between an HTTP/1.2 user agent and origin server is supposed to determine exactly which headers meet criterion (b).

For example, "Alternates" might be a reasonable bet, but this is a manner of interpretation, since as far as I can tell the current draft does not otherwise specify any normative behavior at all for an HTTP/1.1 cache in receipt of an Alternates header. In any case, the working group might change the spelling of "Alternates" to "Variants", or to add some sort of more general Negotiation-control header which subsumes it. Given that multiple incompatible content negotiation proposals have already come out of this WG over the past year or so, I as an implementor don't feel comfortable excluding either possibility, which makes it very difficult to determine how I should treat any particular header in any code which I might be writing now.

Accordingly, I'd like to respectfully suggest that change here is needed. As a strawman, here's a set of rules that I personally would be a little more comfortable with (though it's entirely possible that they have problems which have escaped my cursory review):

a') A response MUST include any values which might differ from those which were received with a prior 200 response.

b') If a response comes from an origin server directly, it MUST include any values that caches use for matching requests and responses with cache entries by caches of its protocol version or better, and SHOULD NOT include any other values.

c') If a response comes from a proxy, it MUST include all values received, *except* those on an explicit, normative stop-list.

(I understand that some of you don't like normative lists. However, a proxy cannot in general know the protocol version of the origin server, since the response may have been downgraded by an intermediate proxy. Likewise, a caching proxy which has to generate a 304 for a resource which is fresh in its cache may never have seen a validating 304 from downstream for that resource. Given all that, passing along everything not on a normative stop list is the only thing I can personally think of that allows new negotiation-related headers to be added to future versions of the protocol).

There is some more minor stuff (e.g., certain questions about responses from caches in New Zealand and elsewhere which don't always allow clients to force the cache to validate an entry), but I'll save those for later.