Re: can't really be LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo

Larry Masinter <> wrote:
>We can't quite LAST CALL a document which has a technical
>issue unresolved. The technical issue that's unresolved
>is the limitation on accepting cookies while interacting
>with the resource identified by the CommentURL annotating
>a cookie.
>I will state my personal opinion, again, just in case there
>is some additional support for it:
>I think that the complexity inherent in "CommentURL" makes
>it suspect, and that the simplest thing to do is to remove
>it. If there is no CommentURL, then you don't need a policy
>for accepting cookies while interacting with it.
>Too much icing on the cookie, just say no.

	The criteria by which a UA might accept particular cookies in
Set-Cookie or Set-Cookie2 headers, and might include particular cookies
in Cookie headers, are in the specification.  There is no MUST for
acceptance of cookies, nor for sending them.  For a URL obtained via a
commentURL, the UA could apply those criteria, and perhaps include cookies
in a Cookie header when requesting that URL.  It could apply those criteria,
and perhaps accept cookies in any Set-Cookie or Set-Cookie2 header that
accompanies the server's reply, all dependent on the context, the manner
in which the UA has implemented cookie support, and any configuration or
run-time options set by the user.  There is nothing about the commentURL
which requires holding up LAST CALL, unless you want to change the critera,
rather than just making suggestions or adding words of caution in the
comments/explanations.  Just say yes.

	The FQDN issue is another matter.  That's a change in the critera.


 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545

Received on Wednesday, 23 July 1997 16:48:38 UTC