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

Re: FW: revised trusted cookie spec

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Tue, 19 Aug 1997 13:07:43 -0500 (EST)
To: masinter@parc.xerox.com
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-state@lists.research.bell-labs.com
Message-Id: <01IMMHS0BLUA009B95@SCI.WFBR.EDU>
Larry Masinter <masinter@parc.xerox.com> wrote:
>>         What will it take to get across that "privacy" is not the only
>> issue here, nor necessarily a central one when a commentURL is sought
>> to assist in making a decision?
>
>First, privacy considerations were the primary motivation for initially
>disallowing cookies in the first place, and then adding Comment and then
>CommentURL as a way for letting users conditionally accept cookies. If
>you're now claiming that privacy considerations are not the central
>issue for whether a user might want to view the resource pointed to by a
>commentURL, well, what is?

	I do not know what was "the primary motivation for initially
disallowing cookies", nor was aware that anyone or anything associated
with the IETF had disallowed them.  Perhaps more germaine, I do not
know what were the primary motivations for developing RFC 2109, nor
what was discussed during the bulk of its development, nor have any
way to access and review those discussions.  That all was done by
a "sub-group" without archiving of its discussions.  This matter
did not get fully "on-track" w.r.t to IETF standardization principles
until discussions about fixing the bugs in RFC 2109 had commenced,
and the more formally structured HTTP-State sub-group with a formal,
reliably archived mail-list were "implemented".

	I do know, and if need be could dig up the archived messages
upon which I base my "knowledge", that the arguments for commentURL
which led to it's inclusion in draft-ietf-http-state-man-mec-03.txt
where not restricted to concerns about privacy, nor to the special
case in which a user might wish to read it before accepting a cookie.
A full implementation of cookie support would include the possibility
of storing it to disk, and thus utilization of perhaps limited personal
resouces.  It also expands system overhead associated with scanning
the set of accepted cookies for whether they should be included in
a UA's http/https requests, and the network overhead, and possibly
per packet $costs to the user, of including them in request/reply
(entity?) headers.  Even in the case of cookies from a site which
the user, for whatever reasons, fully "trusts", the user might at
intervals, or at the end of each session, wish to review any persistent
cookies, so that only those for which a clear, and worthwhile (from
the user's perspective, of course) purpose can be inferred will
actually be retained, e.g., because they will maintain the user's
display preferences for future sessions, or are the "shopping cart"
for an as yet uncompleted shopping spree.   The commentURL also
could be used to assist in cases for which a cookie might need to
be dumped to make room for a new cookie, without relying solely on
a mindless "dump the oldest" heuristic.  We do seem to disagree about
whether the absence of explicit information which might have been
provided, or the substitutions of advertisements or doublespeak, can
themselves be a form of information for intelligent human beings who
have powers of inferrence within the "context" of their personal value
systems.


>If there were other more important considerations, they weren't part
>of the justification used to get the working group to go down this
>particular rathole.

	One must expect problems with initial attempts to maintain
state in what was an inherently stateless protocol, just as one
must expect problems with initial attempts to implement persistent
connections, but this does not make them ratholes.


>		 I understand completely that you have other things
>that you would like to ask content providers to tell you about
>their content and cookies. But if the browser makers mainly don't
>implement it, or if the users don't usually use it (even if the
>browser makers do implement it) then the content providers won't
>provide it, no matter how carefully we add the provisions.
>
>Secondly, if there are any other factors for which users might want
>some kind of conditional compliance, then these are also protocol
>elements with which the mechanisms of conditional compliance should
>be consistent. Right now, users choose 'accept Java' and 'load images'
>using different dialogs and browser options, and there is no protocol 
>element that lets users decide whether they want to allow Java code. 
>Should there be a "comment" or "commentURL" associated with each 
>element of Java, so that I could conditionally decide whether I want 
>to allow a site's Java to execute on my machine, based on a decision 
>of whether it is 'essential' or 'purely decorative'?

	The IETF abandoned (or readily let itself be pushed out of) its
formerly important role in HTML standardization.  Thus, to use your own
immortal word, this comparison to 'accept Java' and 'load images' is
"bogus".


>>       Also, it would be inside Set-Cookie2.  The Big Two are free to
>> continue using just Set-Cookie.
>
>If the makers of an overwhelming percentage of the deployed
>software for web browsing don't intend to show Comment or CommentURL
>data during cookie-choosing, then why in the world would any significant
>number of content providers ever bother providing them? It just
>makes no sense.

	The IETF is not an organization dependent of membership fees
from vendors.  It is, as you once wrote to me, "whoever shows up and
cares".  It seeks to document standards for interoperability on the
Internet, on behalf of implementors be they large and important to
Wall Street, or small ("fringe", from some people's perpspective).
The objectives of interoperability have been achieved in
draft-ietf-http-state-man-mec-03.txt.  Any provider can send
Set-Cookie headers in the historical format for the Big Two UAs,
and upon receiving a Cookie2: $Version="1" request header from a
fringe UA, switch to the superior state management protocol via
Set-Cookie2 headers.  We are for the most part talking about
scripts written by, or for, providers, and they can be implemented
immediately without backward compatibility problems.  You have
not, IMHO, explained convincingly why you choose to keep obstructing
this.

	We both have a problem with some things not making sense to
us.  It makes no sense to me to have a yet-to-chartered WG for
discussing the "process" of URL standardizing, but no WG for discussing
the "substance" of drafts, and instead discussing them in a closed out
URL-WG which is not archiving those discussions reliably.  I don't see
how interoperable results are likely to come from this perversion of the
IETF standardization process.  And frankly, I'm worried that the same
bad situation will apply when this HTTP-WG closes out.

	But the State Management effort did get back on track,
has succeeded, and the -03 draft should move on to an appropriate
Foo Standard status while this HTTP-WG is still chartered.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Tuesday, 19 August 1997 10:20:13 EDT

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:51 EDT