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

Re: Unverifiable Transactions / Cookie draft

From: Larry Masinter <masinter@parc.xerox.com>
Date: Sun, 16 Mar 1997 00:07:11 PST
Message-Id: <332BAA2F.779D@parc.xerox.com>
To: hedlund@best.com
Cc: Dwight Merriman <dmerriman@doubleclick.net>, http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2675
M. Hedlund wrote:
> On Thu, 13 Mar 1997, Dwight Merriman wrote:
> > I would like to propose modifications to section 4.3.5 of the cookie spec.
> > Disabling stateful sessions for unverifiable transactions by default is
> > basically equivalent to not allowing them at all, because 99% of the
> > population will see no reason to change the default.
> It was the explicit intention of the state-management subgroup (as I
> understood it, acting as the notetaker for the subgroup) to disallow this
> functionality unless the user expressly tried to enable it.  Unless I am
> mistaken, the cookie draft has passed last call and is an RFC; and
> revisions are being considered only to address implementation barriers.
> But in any case, here is some history and some commentary.
> First, here are the notes from the state management subgroup meeting in
> which we first discussed this issue.  I believe these notes show that
> balancing the issues of user privacy and server maintainer desires is a
> difficult task.  The 'unverifiable transaction' wording you address grew
> out of this discussion.


Thanks for reminding us of the history of the privacy provisions in the
current cookie RFC. While we can change our minds and reverse a previous
decision, usually this is done when there is consensus that our original
decision was wrong. This doesn't seem to be the case.

Given how often this issue seems to be raised, do you think it would
help to have a more explicit rationale for this design beyond the mail
messages and and the blow-by-blow commentary of the minutes?

I'm thinking that we might try to either add a couple of paragraphs
to the state management document as it moves to Draft Standard, or
else create a separate companion requirements/analysis document.

Received on Sunday, 16 March 1997 00:43:52 UTC

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