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

Re: Removing CommentURL

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Sun, 27 Jul 1997 14:38:59 -0500 (EST)
To: stark@commerce.net
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <01ILQGEWA94Y004I7Q@SCI.WFBR.EDU>
Jonathan Stark <stark@commerce.net> wrote:
>[...]
>You should probably check out the archive... we've debated the idea of
>not accepting cookies during these requests, but some have objected,
>saying basically that it's too dificult to turn cookies off for these
>requests.

	I don't recall anyone objecting, at least, not in the public,
archived discussions, on the grounds that it is too difficult.  The
objection was that handling of URLs, including the sending of headers
in a UA's requests and the processing of headers in the server's
replies, is context dependent.  Only the UA "knows" the full context,
and how "extensive" it is dependents on a large variety of
implementation details which vary across UAs, and on configuration
and run time options that yield variations within particular
implementations.  Most of this discussion has been myopically
restricted to one context:  that in which the commentURL is being
retrieved homologously to an inline or frame and will be presented
to an interactive user as part of an "informed consent" mechanism
before proceding any further with processing of the server's reply
to the original request.  No one has a crystal ball, but I suspect
that will be the rare case, and that if any UA makes that an
obligatory component of its cookie handling, many users will react
to it as if it were a seat belt law.  Given past experiences with
"unverifiable transactions" during inlining, it is understandable
that this WG would want to be sure that a commentURL will not open
yet another door to potentially serious invasions of privacy.  The
specs, themselves, should ensure that no cookie will be transmitted
inappropriately, including during commentURL requests.  Others are
concerned about problematic loops being created during commentURL
requests.  A loop can be broken anywhere in the cycle, the UA is
the appropriate place, and any implementor who couldn't deal with
something as obvious as that, in a manner appropriate for the context,
which is co-dependent on details of the implementation and the user's
configuration and run time options, is probabaly not implementing a
UA you'd want to use, anyway. :)

	In most cases, and particularly first contacts with a site,
users may wish to see (or palpate, or listen to) the document before
making any final decisions about cookies that were associated with
it.  If the document proves not of interest to the user, there may
be no point retaining any cookies associated with it, nor in reading
(or palpating, or listening to) any comments about them (advertisers
versus users, of course, may disagree about that).  If the user is
interested in the document and potentially others via it's links,
then review of associated cookies via their commentURLs may be
appropriate, and less likely to be perceived by the user as yet
another unsolicited WebNuisance.  The commentURL might be used days,
weeks or years after the cookie was received, as part of a "cleanup"
because disk space is running out.  A UI might use it for informed
decisions on which cookie to dump when making room for a new cookie,
rather than relying on an arbitrary "dump the oldest" heuristic.


>[...]
>The reasons FOR commentURL are many:  (Please add any I missed...)
>	1. International Language Support
>	2. Less Bandwidth (as compared to Comment)
>	3. Much more versatile and "rich" than straight text.
>	4. A URL is more easily maintained than information in a
>		Script, hence it's more likely that the data found
>		at CommentURL will be updated than in comment
>
>The reasons against (and somebody from the other side of the camp
>please add on here..)
>	1. It's too difficult to implement CommentURL
>		(Though, strangely, some against CommentURL think it would
>		be better to include CommentURL in Comment, having the
>		browser search for URL's and handle them appropriately)
>	2. Why have commentURL when we have comment...

	That reads like a stacked deck, but indeed reflects how
compelling the reasons for versus against have been thus far.

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Sunday, 27 July 1997 11:43:11 EDT

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