W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > May to August 1996

Re: Conventions for Sharing User Agent Profiles

From: Koen Holtman <koen@win.tue.nl>
Date: Thu, 15 Aug 1996 19:59:37 +0200 (MET DST)
Message-Id: <199608151759.TAA04972@wsooti04.win.tue.nl>
To: Koen Holtman <koen@win.tue.nl>
Cc: ses@tipper.oit.unc.edu, koen@win.tue.nl, mogul@pa.dec.com, jg@zorch.w3.org, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/1359
I wrote earlier in a reply to Simon Spero:
>I don't see how you can ever get the numbers working for user profile

After reading Simon's HTTP-NG proposal, I must add something here.  It
seems that HTTP-NG proposes a lot more than just user profile caching,
and additional mechanisms in the proposal *will* make the numbers work
for HTTP-NG in the case I analyzed in my earlier message.

Summarizing what I read Simon's text, it seems that HTTP-NG is not
proposing plain profile caching as a negotiation scheme, but a
PEP-like negotiation scheme, in which the initial request is kept
small by allowing the server to go back and ask for more profile data.
In HTTP-NG, profile caching would only be an optional optimization on
top of the PEP-like scheme.  I thought that Simon's profiles would be
5K chunks of data containing all information about a particular area
of negotiation.  Instead they will usually only contain those
capabilities and preferences the server actually asked for in the

I also wrote:
>It seems to me that only transparent content negotiation scales for
>P_same values of 1 in 1 million or more (while also still protecting

I now think that HTTP-NG negotiation will also scale for these P_same
values, and that it will also allow privacy to be protected.  It is
plain user profile caching, without any additional mechanisms, that
won't scale.

I think that the HTTP-NG form of profile caching could also be
effective as an optimization on top of transparent negotiation (in the
case where many requests are done on the same server).  The
optimizations I have now in the transparent negotiation draft don't
concern themselves, like HTTP-NG does, with squeezing every last byte
from the request message.  They instead cut RTT delays by using proxy
caches to respond to the request whenever possible.

As for the main problem discussed in this thread, how to share data
for negotiating around bugs the browser vendor does not care about: it
seems that an internet draft to solve this problem would have to
define a substantial amount of new stuff, beyond what is now in both
HTTP-NG negotiation and transparent negotiation.

Received on Thursday, 15 August 1996 11:02:59 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:17 UTC