- From: Jonathan Stark <stark@commerce.net>
- Date: Tue, 22 Jul 1997 14:53:02 -0700 (PDT)
- To: Foteos Macrides <MACRIDES@sci.wfbr.edu>
- Cc: http-wg%cuckoo.hpl.hp.com@hplb.hpl.hp.com
> >If the user agent allows the user to follow the [CommentURL] link [as > >part of a cookie inspection user interface], it should neither send nor > >accept a cookie until the user has completed the inspection. I think that's absolutely correct. It's the only way not to confuse either a script on the server side, or the state on the UA side. > I don't see why you want to exclude sending of cookies when > a UA is acting on the commentURL, nor why you are conceptualizing it > as only for a policy statement. That's possible, but the PEP or > PEP-like extension is a better way to assess a site's "policy". One > of the main reasons for wanting cookie support in UAs is that it's a > simple, "here now" way to maintain user preferences across documents > at a site, and is complementary to the TCN/features mechanisms. The > hope is that the reply will include a statement about the purpose of > that particular cookie, and "preference cookies" should still be able > to affect how the reply is structured. The reason for not sending or accepting cookies is that the whole purpose of the CommentURL is to allow the user to evaluate the pros and cons of accepting a cookie. If you offer another cookie while they're trying to decide if they should accept the first cookie, now they potentially have to evaluate whether they want to accept the second cookie, presumably before they can even look at the information explaining the first cookie. Obviously, this could be a very annoying endless loop to nowhere. We also don't want to appear to be advertising to the Server that there's an opportunity to change the state on this particular user while he grabs the CommentURL. Sorry for the wording here, but if the server expects the client to accept the change on a cookie that IS already being used, and the user agent doesn't accept the change because it's retrieving a CommentURL, the applications on the server side may become confused. > You simply want to guard against the server trying to set new > cookies via the reply to the commentURL request, and there too, you > need not exclude things like it expiring or modifying old cookies > which the user accepted. How about something like this: > > If the user agent allows the user to follow the CommentURL > link as part of a cookie inspection user interface, the server > should not include any new cookies in the reply, and the UA > should allow the use to inspect the body of the reply before > acting on any other commentURL links. You can't put the responsibility for this on the server. It must be in the client. At the very least, the client should ignore any "new" cookies. I think, however, it best to not accept any cookie actions while getting the commentURL document. Some scripts may not react well to having a cookie expire, and having another cookie that was issued in the same request not get set. The "correct" action would be to feign ignorance of cookies and do nothing to the state of the UA until a decision is made on accepting or refusing the original cookie in question. As stated in the original message, the UA should also not send any cookie information when retrieving the CommentURL. > If this is a "first contact", or is consequent to the user having > enabled formerly disabled cookie support, that degrades to the > reply having no more than the cookie about which a comment is being > sought. > > Fote ouch... parse error line 3... sorry... The reply to what? To the request for the CommentURL? The UA just needs to know if it should or should not accept a cookie that's been sent to it. The CommentURL allows the user to make an informed decision about whether they should or should not accept the cookie. The process of attaining this "decision making information" should be "sacred"... without cookies or sessions or anything... it should be anonymous, as though the browser does not have support for cookies, and it should not be something that will result in any cookies being accepted, rejected, or changed in any way, except for the one cookie that is in question, and the point of the whole process. Jonathan
Received on Tuesday, 22 July 1997 14:59:55 UTC