Unidentified subject!

First let me say that I appreciate all the work Jeff and Paul have
done on this, and that I think the work item needs to move forward.
As a counterpoint, though, I need to say that we really haven't had
enough discussion about this in the working group.  The design choices
in this draft imply a lot about how proxies will work, how connection
information might perdure, and what information dissemination model
the web will use in commercial space.  These are crucial issues and I
think we need to focus on them.  I've made a few comments below, but
there are lots of talking points in the draft that require data that I
don't have.  I urge anyone with access to the proxy hierarchies that
this would impact to report on their experience.  I've made a few
specific comments below, but I think they are only a portion of the
broader discussion needed.


Specific comments:

For readability, I would move the section in 1.2 which describes what
cache-busting includes into the Introduction; I believe it would help
clarify what problem is being addressed.

It's not clear to me what "no additional network round-trips in any
critical path" means--where is definition of "critical path" in this
context?

In your design question in section 3.1, you note that having the
origin server add the "Cache-control: proxy-mustcheck" to the response
would get the proxies out of the business of adding headers to
responses, and I think that this a very good thing.  I am concerned,
though, about exactly how to define the Connection: proxy-mustcheck
(or max-age=0) header in that case, since the proxies' behavior varies
(depending solely on a Meter offer and Meter response? or those and
others?)  In particular, how does this affect the behavior of the
proxies when the server sends a Meter: header without having had the
proxy volunteer (see Note in Section 3.3 near the bottom of page 11)?

As I noted on previous drafts, I'm unsettled with the idea of the
proxies' first use of this header being defined as applying to all
subsequent requests made on the given transport connections; I
appreciate the implementation advice, but I still believe that the
problem should be solved generally.  If we do come to a general
solution of "sticky" headers and it doesn't match this model, we have
a serious piece of cruft.  How important is it not to repeat these
particular bits on the wire?  I would much rather limit the bits by
including only the abbreviated forms of the directive and responses
than by making a de facto sticky header.

As an editorial thing, I think that the "Note on the limit on 'uses'"
text in 3.3 needs to be incorporated fully into the text and flagged
in big, bold letters.  You may also want to think about what this
means for the interpretation of a Meter: count=0/0 report in the
presence of pre-fetching.

I think section 8 needs to reference Koen's draft on multiple variants
and it may need to define what to do in border cases.  If, for
example, a meter-willing cache offers a list of variants to a an
end-user and it declines all of them, should that be reported?

I think section 8,the note on capturing referrals, doesn't seem to
belong in this draft, unless the scope is larger than the goals
statement implies.


As I said, thanks for all the work on this,
			regards,
				Ted Hardie
				NASA NIC

-- 
Ted Hardie

Received on Friday, 31 January 1997 14:42:05 UTC