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

Re: Issues with the cookie draft

From: Larry Masinter <masinter@parc.xerox.com>
Date: Tue, 18 Mar 1997 22:21:59 PST
Message-Id: <332F9417.16F4@parc.xerox.com>
To: Yaron Goland <yarong@microsoft.com>
Cc: http-wg@cuckoo.hpl.hp.com
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/2742
> My alternative proposal is to remove section 7 of the current draft and
> to make the other alterations I have specifically suggested in the rest
> of the post you referred to below. Would you like me to do a little
> cutting and pasting and actually make it into an I-D  

I will respond to this as if you meant it seriously.

I think my request was very clear: a separate Internet Draft which
explains the proposal, its justification, and the way in which it
addresses the concerns about user privacy which led to the current

If your proposal is "remove section 7 of the current draft", then you
still have something to write, since I have yet to see anything that you
could cut and paste that would  explain the situation sufficiently to
mollify the concerns expressed here and elsewhere how user's privacy is

> should we
> continue to discuss the basic issue of how far this group should be
> going in its protocols? 

Absolutely not.

Insofar as the IESG accepted RFC 2109 as a valid IETF protocol
specification, we have had a clear reading of the validity of scope. You
may believe that we have so far come to an incorrect engineering choice
(which is why you've been invited to propose an alternative), but not
that we have no right to make such a choice.
It is true that vendors can ignore what we write. In general, IETF
standards actually have no enforcement clause. Vendors can implement
whatever they want, no matter how broken or divergent from proposals
agreed to here. Ultimately, what the implementors implement and the
users use determines what the real standards are. From this point of
view, if a group with sufficient marketing clout creates products that
countervale our best judgement here as to how to deal with user privacy
issues, well, then they'll just do it. You needn't remind us of this. 

However, the alternative to a standard that addresses the percieved
requirements of protecting user privacy is "no standard". That is, we
cannot merely "remove section 7 of the current draft" and be done with
it. The requirement is real, what we're asking for (once more) is a
credible explanation of how the privacy issues are (or are not) dealt

Received on Tuesday, 18 March 1997 23:24:02 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:01 UTC