- From: Koen Holtman <koen@win.tue.nl>
- Date: Mon, 24 Mar 1997 22:12:49 +0100 (MET)
- To: Jeffrey Mogul <mogul@pa.dec.com>
- Cc: http-wg@cuckoo.hpl.hp.com
Jeffrey Mogul: [...] > ftp://ds.internic.net/internet-drafts/draft-ietf-http-hit-metering-01.txt > [...] >To this date, I don't think there have been many (or any) comments on >the Design Notes/Design Questions identified in the draft. Consider >this as your last change to discuss those notes. I just read the design notes, and I agree with the way you have resolved the known design choices. > If there is no >specific and unresolved discussion of these notes, I will remove them >and generate a new draft by the pre-Memphis I-D submission deadline >(next Wednesday, March 26). Some other quick comments: - I'm happy with the new material about user counting. This revision removes my earlier concerns about the support for user counting being overstated. - Some exotic proxy arrangements could lead to there being a `metering sub-graph' instead of a tree. Have you done the analysis to find out if section 5.6 really covers all subcases? - Section 3.3: `then the proxy MUST add "Cache-control: proxy-maxage=0" to all responses it sends for the resource.' You probably mean: `then the proxy MUST add "Cache-control: proxy-maxage=0" to all responses for which metering or limiting was requested.' because you say earlier on that being metered is a property of a response, not of a resource. - Section 4.1: `The existing (HTTP/1.0) "cache-busting" mechanisms for counting distinct users will certainly overestimate the number of users behind a proxy, since it provides no reliable way to distinguish between a user's initial request and subsequent repeat requests caused by insufficient space in the end-client cache.' Hit metering also `provides no reliable way to distinguish between a user's initial request and subsequent repeat requests caused by insufficient space in the end-client cache' if I'm correct (there is no If-* header if the page dropped out of the cache), so limiting this statement to "cache-busting" is a bit misleading. `The "Cache-control: proxy-maxage=0" feature of HTTP/1.1 does allow the separation of use-counts and reuse-counts, provided that no HTTP/1.0 proxy caches intervene.' How can they intervene? Do some 1.0 proxies stip off the If-NoMatch headers when forwarding a request on a stale cache entry, or are you talking about something else? - Concluding: I can live with this draft going forward as a proposed standard. I think it is technically sound. I'm converting my `no' on the previous last call to a `don't care'. It is not a `yes' because I still feel there is insufficient evidence that this draft is really needed. >-Jeff Koen.
Received on Monday, 24 March 1997 13:20:09 UTC