RE: New document on "Simple hit-metering for HTTP"

>----------
>From: 	hallam@ai.mit.edu[SMTP:hallam@ai.mit.edu]
>Sent: 	Friday, August 16, 1996 5:57 PM
>To: 	http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
>Cc: 	hallam@ai.mit.edu
>Subject: 	Re: New document on "Simple hit-metering for HTTP" 
>
>
>Hang on a sec, of the 3 drafts only one was to do notification.
>
>I don't think that length of the draft is a good way of measuring
>the complexity of the draft. I thought spliting drafts up was
>flavour of the month :-)

That's why I said it was a crude measure.
>
>The others are linked insofar as they extend the functionality
>but the core of the notification idea is the same size.

But just being notified isn't enough, right? The proxy has to implement
the extended log format in order to transfer the information in a
standard way, and so on with session IDs.
>
>What I am more worried about is that the people are increasing the
>requirements beyond those originally met by "simple" spec. Or
>to put it another way, by the time you meet the demands of the
>various advertsing brokers you may well be looking at 26 rather than
>11 pages (closer to 40% than 1/3 :-).

Sorry -- that was a thinko -- if you assume 2 pages of boilerplate per
draft, your 3 have 20 pages of real text and ours has 9 -- closer to
>50%, actually. Even at 1 page of boilerplate per draft, it's 10/23....
>
>One factor you will have to take account of is the need to forward
>session id information. This means either trapping cookies or
>some sort of explicit session id such as I proposed. The value of 
>advertising is very heavily dependent on the demographic profile.
>Look at doubleclick where demographic constraints increase the
>cost of a 100,000 hits from 9K to 29K.

Part of our draft is just a note about how to get referer information
without adding to the protocol.
>
>Personally I prefer my session id scheme :-)

I'm not knocking your scheme -- its clearly the only approach to getting
all the information one would get if the origin server saw all the
requests. I'd be quite happy if everyone said they were really going to
do it your way, and it got deployed really soon. I was only objecting to
the characterization that ours is just as complex. I don't really want
to spend a lot of time trying to quantify their relative complexity  --
it would be better spent getting both approaches through the
standardization process so that the decision can be made the way it
usually is -- by implementors and customers voting where they want to be
in cost/benefit/time-to-implement/time-to-deploy space.
>
>

Received on Friday, 16 August 1996 18:29:17 UTC