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

Re: commentURL, again.

From: Larry Masinter <masinter@parc.xerox.com>
Date: Mon, 18 Aug 1997 13:32:42 PDT
Message-Id: <33F8B16A.F3C3DC66@parc.xerox.com>
To: Judson Valeski <valeski@netscape.com>
Cc: "'http-wg@cuckoo.hpl.hp.com'" <http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com>, "'http-state@lists.research.bell-labs.com'" <http-state@lists.research.bell-labs.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/4210
> Consensus in Munich (which does not include many concerned with this
> issue) was that comment/commentURL is to be taken out of the spec, which I
> believe is the right thing to do. How is this formally done? Let's do it.

What happened in Munich was not 'consensus', but a straw poll of the
It was uniform, but of course, most of the concerned parties weren't

The way in which things are formally done is that issues are raised on
the mailing list, and when the mailing list converges, we call for

> Why it shouldn't be in RFC 2109:
> - RFC 2109 is concerned with the functionality of cookies/stateful
> sessions.

RFC 2109 is concerned with both the functionality of cookies & stateful
sessions and also addressing the privacy considerations that come with
that functionality.
> - It is not the protocol's place to include this type of explanatory
> information to the user (if it belongs anywhere, it belongs in another
> spec related to privacy concerns and cookies; as suggested by Larry
> Misinter).

It most definitely *is* the responsibility of a protocol designer to
the security issues surrounding the use of the protocol, and within
the IETF, working groups are required to address security and privacy
considerations within protocol documents.

It is my personal (not WG-chair) opinion that this particular privacy
concern should be addressed elsewhere within HTTP, but that the 'fix'
doesn't belong directly within the Set-Cookie protocol element.

It is my WG-chair opinion that progress on the protocol itself
has been held hostage to the current language in the protocol
description dealing with the privacy issue, and that one
way to make progress might be to split the document but not
the specification. (This would allow the privacy considerations
section to be revised even if the protocol specification
was not.)

Received on Monday, 18 August 1997 13:40:42 UTC

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