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

Re: 305/306 response codes

From: Koen Holtman <koen@win.tue.nl>
Date: Tue, 17 Jun 1997 21:25:18 +0200 (MET DST)
Message-Id: <199706171925.VAA16348@wsooti08.win.tue.nl>
To: Yaron Goland <yarong@microsoft.com>
Cc: josh@netscape.com, http-wg@cuckoo.hpl.hp.com, vinodv@microsoft.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3542
Yaron Goland:
>In general it just seems fairly clear that using response codes to
>perform proxy configuration is a bad idea. It may sound sexy but as the
>myriad problems so far raised demonstrate, there are a lot of difficult
>issues that are not going to get solved with a single HTTP round trip.
>My suggestion is that we cut 305 from the HTTP 1.1 draft and let the
>draft continue on its merry way. This issue can always be revisited in a
>separate draft.

I agree.

In particular, I think we need a lot more of a trust management
infrastructure before something like this can be deployed.  Asking the
user for confirmation on various actions is not good enough as a
solution for keeping things secure, because the average user will have
a hard time understanding all the implications of clicking `OK'.
Compared to this, understanding the implications of accepting a cookie
is easy.

Also, am I reading it wrong, or does the draft currently require not
only user agents, but also proxies to ask for user confirmation?

Josh: On the issue of whether feature negotiation can replace the use
of the OPTIONS method: it cannot if you mean the feature negotiation
found in TCN, because TCN does not negotiate on protocol options.  You
could use PEP for it, but that would be overkill for an IETF-defined
mechanism, so I think OPTIONS is a good choice.

Received on Tuesday, 17 June 1997 12:27:33 UTC

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