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

Re: Removing CommentURL

From: David W. Morris <dwm@xpasc.com>
Date: Sat, 26 Jul 1997 11:49:31 -0700 (PDT)
To: Larry Masinter <masinter@parc.xerox.com>
Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com, http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
Message-Id: <Pine.GSO.3.96.970726112228.13755F-100000@shell1.aimnet.com>
X-Mailing-List: <http-wg@cuckoo.hpl.hp.com> archive/latest/3934

On Fri, 25 Jul 1997, Larry Masinter wrote:

> Since this argument seems to have convinced one person,
> I thought I would make it more broadly and see if I could convince
> someone else.

The suggestion is that CommentURL won't be used much or help many
users so it should be dropped.

The fact is that there has been significant push back on even implementing
the IETF cookie specification from the two largest UA vendors. 

There  is also the reasonable hypothesis that most users will, totally
confused by the issues and frustrated by the interruptions, simply
enable all cookies.

On the basis of lack of deployement or lack of appeal to the general
user we should simply drop all concerns about cross domain cookies or
drop the cookie issue with a simple RFC which overrides 2068 as not
implementable and to be ignored.

I am not advocating that approach, only noting that the same arguments
made against the utility of CommentURL apply to the broader set of

I do seriously propose dropping the Comment attribute as so inadequate
for its stated purpose as to be meaningless. Eliminate the confusion and
simplify the protocol.

In any case, there are clear failings for comment for its stated purpose
of informing the user of the intended use of the cookie. It would be
irresponsible protocol design to not provide the more complete approach
in the protocol.  Protocols insure interoperability and speculation that
a UA might parse the comment field and recognize an arbitrary character
string as a URL and so present it to the user is not interoperable 
protocol design. I would certainly not want to get into design and
specificatation of the content of the comment field to make that
alternataive interoperable. The only technical issue with CommentURL is
the question of cookie handling when the commenturl is presented 
during a cookie inspection dialog. That same exact issue exists for
URLs imbeded in a comment field.

CommentURL is clean, covers internationalization issues and is infinitely
extensible from a content perspective. It makes good protocol. We can't
force users to use our protocols but we can make sure that the protocol
delivers the function described.  Comment does not meet that test.

Dave Morris
Received on Saturday, 26 July 1997 11:51:53 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:40:20 UTC