- 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
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 UTC