Re: Hit-metering: to Proposed Standard?

> Although our previous (and quite different) proposal, at the end of July,
> resulted in some discussion, this one has raised no comments on the
> mailing list (although we have received a few private comments).
> 
> Since we have not seen any criticism of our latest proposal, we would
> like to interpret this as lack of criticism rather than lack of
> interest, because we already have evidence that several large customers
> are eager to deploy implementations of our proposal.

My comments on your last proposal still apply to this one. From
   <http://www.ics.uci.edu/pub/ietf/http/hypermail/1996q3/0396.html>
==================
["coop" is now called "Meter"]
that is not an appropriate use of Connection.  For one thing, assuming
that all intermediaries have caches (and thus would assign any meaning to
being cooperative) is wrong.  For another, it doesn't take advantage of
the extensibility mechanism inherent in cache-control.  Instead of all
the coop negotiation, an origin server should decide whether being
cooperative is required or optional.  If it is required, then send

    Cache-control: proxy-revalidate, coop

with coop (or something similar) being defined as a modifier on
proxy-revalidate such that caches which obey the coop directive
(whatever that may imply) may ignore the proxy-revalidate.
If cooperation is considered optional, then just send

    Cache-control: coop

The advantage here is that you don't need to mess with Connection and
the directives will propagate to all recipients instead of just the
nearest neighbor on the response chain.
==================

When I said the above, I should have been more clear in my objection.
Connection cannot be used as a means for two caches to communicate because
not all proxies have caches.  Requiring that a non-cache proxy fiddle
with Cache-Control on the basis of what they must drop from Connection
is just not appropriate.  Use a design which doesn't fail through such
proxies.

In addition, the current design, if implemented, forces the proxy to add

    Connection: Meter
    Meter: will-report-and-limit

(or "wont-report" or "wont-limit") to every single request forwarded,
regardless of the likelihood that the origin server and the requested
resource happen to use hit-metering.  In other words, "good citizen"
proxies are forced to do extra work on every request just to support
a few "bad citizen" service providers who are too lazy to perform
statistical sampling.  Any reasonable estimate of the percentage of
resources requiring "hit-metering", versus those that don't, will show
that the amount of extra bytes sent by the proxy to support those
few lazy servers will far exceed the amount of extra bytes that would be
sent by cache-busting.  As such, the proposal is actually less efficient
for the Internet than doing nothing at all.

> P.S.: We should also note that Larry Masinter has suggested that
> this should be submitted for "Experimental" rather than "Proposed
> Standard" status.  Our reading of RFC2026, however, convinces
> us that "Experimental" would be inappropriate.  Larry may still
> disagree.

Again, my previous comments still apply to this proposal.
==================
I still don't believe that such count-forwarding is appropriate for a
proposed standard (experimental is okay), since I don't think that
people disable caching just to record hit-counts (which are already
known not to be an accurate measure of readers).  Most people disable
caching by accident, and those that do it on purpose are normally
looking for Referer and IP/hostname (more than just a request count).
==================

I do not believe that the proposal is valuable to the Internet community.
In fact, I believe it will cause more harm than good if implemented,
and would strongly recommend not implementing it as it currently stands.
On that basis, I oppose it going forward as a Proposed Standard.


 ...Roy T. Fielding
    Department of Information & Computer Science    (fielding@ics.uci.edu)
    University of California, Irvine, CA 92697-3425    fax:+1(714)824-4056
    http://www.ics.uci.edu/~fielding/

Received on Wednesday, 20 November 1996 03:07:32 UTC