Re: Removing CommentURL

David W. Morris wrote:

> cookie. Secondly, has has been pointed out, there is no
> internationalization support in the comment, thirdly the ability to stick
> a URL in comment text ... so what?

The internationalization benefit that comes with the commentURL attribute is a defensible argument and it is quite convincing. I'm wondering if maintaining comment attribute character set information is the solution?

> If commenturl is a supported
> attribute, service implementors at least have a hint that providing a
> URL is desirable.  UA implementors know that actually implementing
> URL clicking is expected ... suppose the comment includes a URL, do
> you then expect the user to open a new UA window and cut and paste the
> value or do you propose that UA's be required to recognize a URL
> in the comment text and make it clickable ...

This is what I'd propose. I wouldn't consider it a "requirement" however. A semi-capable UA would just implement it, if it so desired.

> that is a more complex
> implementation than what we've proposed and it has all the same worries
> about nested cookies, etc.

I'm not sure nested cookies are really a concern. If the user is that interested in reading about the cookies being set on his machine, then he can read about every one associated with every commentURL that comes down the pike. If that spins him into a spiral he should tell his content provider not to set cookies when a request for a commentURL comes in. If content providers, malicious or not, don't abide, users will stop viewing commentURLs and then the attribute's very intent has been defeated. Or a simple solution
would be to not allow cookies to be set/sent when a request goes out to a commentURL.

I'm beginning to wonder about the need for any comment/commentURL attribute at all. If the user/customer is the one driving this issue ("I want to know what data is being stored on my machine"), I'm of the belief that actually he is not, perhaps the same informational URL that has been proposed to be placed in some attribute associated with a cookie should simply be made available on the site the user/customer is visiting (at the discretion of the content provider of course, just like his willingness to fill out a comment
attribute). Rather than placing the responsibility on the protocol to provide potential confidence about a cookie, shouldn't it be placed on the content provider. Cookies are a mechanism by which one can store potentially stateful information and various bits of data, not one that provides a privacy issue/non-issue communication channel.

Judson Valeski

Received on Saturday, 26 July 1997 13:37:36 UTC