Re: LAST CALL, "HTTP State Management Mechanism (Rev1) " to Propo

dmk@research.bell-labs.com (Dave Kristol) wrote:
>Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
>  > 	The commentURL points to a resource which can be requested by
>  > a UA under a variety of circummstances, not just in conjunction with
>  > an assessment of whether to accept a new (not previously accepted or
>  > expired) cookie, or an assessment of whether to delete a previously
>  > (e.g., tentatively) accepted cookie.  A link for that URL might have
>  > been bookmarked, or added to some document.  The server thus must be
>  > prepared to have Cookie headers in requests for those resources, and
>  > should act on them as it would for other requests sent by UAs.  If
>  > you impose restrictions for such URLs, you are creating complications,
>  > not alleviating them.
>
>Not really.  The server has to be prepared not to receive the cookie
>back in any event.  Also, the complications I was trying to alleviate
>were on the UA side, not the server side.

	That sounds as though we agree but haven't both realized it yet.
This is almost entirely a UA issue.  The server may or may not act
on any cookies the UA sends, and the UA may or may not send any, which
is already encompassed by the specs as they presently stand.  As far as
my UA is concerned, if it has a cookie that qualifies for inclusion in
a Cookie header for the commentURL based on the specs, and isn't
disqualified based on any additional configuration or run-time options
set by the user, and for example is being used to maintain a preference
for documents that are suitable for a braille interface or speech
synthesizer, I don't see why it shouldn't be included, with the user,
of course, crossing his/her fingers that the server respects it and
doesn't return glitz and blitz for GUIs.


>  > 	In those cases where the UA is sending the request in conjunction
>  > with an assessment of whether to accept a new cookie or delete an existing
>  > one, I still see no compelling reason to omit a Cookie header from the
>  > request, if there are cookies which the UA would normally send to that
>  > site.  I also think it is desireable to send at least the cookie for which
>
>Think again about that.  Suppose site a.com sent cookie X=1 previously.
>I go to a.com again, send cookie X=1, get a new cookie, X=2, and pop up
>a cookie inspection dialog.  CommentURL directs me to a URL on a.com.
>I certainly don't want to send X=2:  that's the cookie I just got, and
>I'm trying to decide whether to accept it.  But I just sent X=1.  Does
>it help to send it again in this context?

	If the filters imposed by the basic specs are not adequate in
this case, then they are inadequate, period.  I think it is desireable
to send at least one cookie, which in the case of a commentURL being
requested in an "assessment" context must have been in a Set-Cookie2
header, and thus will be sent with a $VERSION leader, signaling a
modern implementation.  If no cookie qualifies after applying the
spec's filters and any additional contraints configured or imposed
at run-time by the user, then none will be sent.  Life always has
its hard knocks. :)


>  > a comment is being requested, to ensure that at least one cookie is
>
>On the contrary.  I haven't decided whether I want to accept that cookie.
>Why should I send it back before accepting it?

	This is mere semantics.  You've tentatively accepted it, or you
wouldn't be seeking the body of a commentURL, and will decide whether to
discard it or not after receiving that body, hopefully with a charset
and language that allows you to read it and make an informed decision.


>[...]
>I remain unpersuaded.  It would help me if you would comment on my
>proposed words and/or, especially, if you would propose words you
>consider suitable in their stead.

	I did send alternate wording, as did Dave Morris.

	Here' my effort at a synthesis that might yield consensus:
	
	A potentially confusing situation exists if this sequence occurs:
 	 - the user agent receives a cookie that contains a CommentURL
	   attribute;
	 - the user agent's cookie inspection interface presents a dialog
	    that allows the user to follow the CommentURL link; and,
 	 - when the user follows the CommentURL link, the origin server (or
	   another server, via other links in the returned content) returns
	   another cookie.
	The user agent MAY discard any cookie received in this context
	that the user has not, through some user agent mechanism, deemed
	acceptable.


Note that the user agent MAY discard *any* cookie it receives in *any*
context, so this comment/explanation doesn't change anything that is in
the -02 draft, and could not validly be construed as a reason for postponing
LAST CALL.

				Fote

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

Received on Wednesday, 23 July 1997 17:22:57 UTC