- From: Jonathan Stark <stark@commerce.net>
- Date: Mon, 24 Mar 1997 20:10:44 -0800 (PST)
- To: hedlund@best.com
- Cc: stark@commerce.net, http-wg@cuckoo.hpl.hp.com
Quoting Marc Hedlund: > Jonathan, thanks for reviewing the RFC. > > On Mon, 24 Mar 1997, Jonathan Stark wrote: > > I would like to have a CommentURL which contains the path to comments > > regarding the privacy policies of the site that deal with the cookie. > > The potential loop problem (setting a cookie on the cookie information page > -- which you address in your proposed language) is pretty funny. Yeah, it is funny... But I don't think most people who are using cookies are going to necessarily think about taking the extra effort to exclude a certain page. > I think this suggestion creates UI weirdness -- the proposal seems to > assume that the client can open a second window for review of the policy Perhaps. I think the prefered method would be a unique dialog box that happens to have html in it... I think it's important that the user deal with this issue before proceeding, and that it look uniquely different that JUST another web page, and the only real way to do that is if the browser makes the window look a little bit differnt. But that is UI... it's not really our problem here as I understand it. It's good to think of it's limitations, though. Does anybody who's worked on a browser have any comments? > before making an accept/decline decision on the cookie. That may not be > true for, say, a Pilot Web browser, or other limited-UI browsers. I don't Good point. Is it reasonable to accept a browser to be able to make two connection at a time? I'm not sure. Maybe those browsers would need to acquire the ability to make multiple connections or just not support this feature. > > I like David's point about language negotiation being handled through the > follow-up request, though. I'm afraid I don't fully understand this issue. Language negotiation is a part of the cookie spec? I think I missed that part. Somebody wanna point me at a URL? > > I would like this URL to be relative to the URL that issued the cookie, > > unless otherwise specified (as being server relative or fully qualified). > > Hm....what if I want to reference the generic eTRUST cookie policy (if such > a thing were to exist) at the eTRUST site? Then eTRUST could say, "5 > million people examined our cookie policy before accepting a cookie this > month, so privacy is important to them." (My point being that there is > value to centralized policies, and thus absolute commenturls, be they for > privacy advocates or Better Business Bureaus or whatever.) I agree completely. But we would get that information from logs or a cgi that counts the hits. What I said (meant to say?) is that they should be interpreted EXACTLY as a src="..." field in the body of an html doc. ie, a request to "http://www.etrust.org/thing/text.html" could have the following values in ComentURL translating to the following pages: policies.html -> http://www.etrust.org/thing/policies.html /policies.html -> http://www.etrust.org/policies.html http://privacy.goodguy.org/disclosure.html -> http://privacy.goodguy.org/disclosure.html My purpose in doing this is to make the commenturl value as short as is reasonably possible. The code in most browsers is already there to expand server and page relative URLS, so use it. > > > CommentURL=commenturl > > How about > CommentURL = '<' commenturl '>' I'm new to this whole process, so I guess I don't understand the difference in notation. Does this now imply that the attributeline would look like this: CommentURL=<http://www.privacy.net/disclosure> ? If so, I disagree. It should be parsed the same as all the other attributes... CommentURL=http://www.privacy.net/disclosure However you notate that.... :) I'm not sure... are there problems with escaped characters in a URL meaning something in the Cookie? Somebody help me out here... Maybe <> is necessary? > > Optional. The CommentURL allows an origin server to specify a document > > that explains the usage of this cookie, and could optionally also explain > > the policies governing the use of information collected through this cookie. > > Add: "A server SHOULD send a comment if sending a commentURL, for use by > those browsers unable to display the CommentURL contents." I question this a little bit. My goal (in addition to the one you pointed out, in providing a common location for collecting policies) is to reduce the amount of data that has to be sent to the client. If you send a comment AND a URL, that doesn't really achive my goal. I suspect that "the market" will dictate it's own rules on using one or the other or both based upon the implementations of the day. And, to some extent, that's probably ok. I guess my point is that the best practices will change over time, and we maybe shoudn't outline a static practice in the RFC. Do others agree or disagree? This is a tricky issue. If you don't set down a best practice, you may not get what you want, but it you do, you may end up outdated. There certainly is value to both methods, and I do see your point. Perhaps the best thing to do would be to recommend that in the absence of a comment, the CommentURL (if present) should be offered to the user in a similar way as the Comment. This isn't extremely graceful, but then someone truly concerned has the option to not accept the cookie originally, and go look at the comment URL even on a browser that only allows one connection at a time. I don't really think I'd like what this would look like, but it's something. > > A user-agent can offer the user the option of inspecting this page before > > accepting a cookie. > > Should be: "A user-agent MAY..." I'll go half way... how about "A user-agent should"? :) > > Any cookies issued while attempting to retrieve the > > document at commenturl should be refused. > > Marc Hedlund <hedlund@best.com> > Thanks for the comments, Marc, Jonathan
Received on Monday, 24 March 1997 20:09:59 UTC