You basically hit all the ones I'm thinking off, more or less.
> ******* I. The Request-ID: header field:
Yup! Would it be asking too much to make this a mandatory, or strongly
recommended, part of the request? With truely random ID's persistant only
for the course of a session, then I don't see how this information could be
resold in a way that compromises security or the privacy of the client.
> ******* II. The business-card authentication scheme
Sounds good - the set of common fields should be laid out somehow. Also,
the authentication response might be a little different - instead of
denying access an information provider might just want to shunt them off
to a separate area. I suppose that can be in the body of the 401
response though. For bandwidth/efficiency reasons, maybe just passing
along a URL would suffice? Perhaps this URL could point to a document in
some sort of regular business-card format, which could just be a list of
attribute: value pairs?
> ok... I've run out of time for doing this right now, but rather than
> stuff it away somewhere, I'm going to go ahead and send it out for
> discussion. The IIIrd proposal is basically the Netscape cookie idea,
> except that it ought to be re-cast as an HTTP authentication
> mechanism.
Cookies also largely obsolete the Request-ID proposal, modulo concerns
about privacy.
> I haven't had time to discuss the privacy issues in detail, nor talk
> about the required but hidden IVth proposal, which is that proxies and
> caches relay certain log info to information providers.
I believe HTTP-NG had automated provisions for this?
Brian
--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=--
brian@organic.com brian@hyperreal.com http://www.[hyperreal,organic].com/