Re: Comments on the new cookie draft

Larry Masinter <masinter@parc.xerox.com> wrote:
>It isn't clear to me that there's consensus behind the two
>header approach. Is there really?
>
>It seems like a big switch in directions; we went through
>a lot of angony to get to a draft that we sent out for
>Proposed Standard. Are we now all changing our minds about
>what we want to propose as a standard and propose something
>else?
>
>I haven't heard a groundswell of "oops, sorry, changed my mind"
>at all. Mainly I see people are grumbling about getting
>backed into a compatibility problem and wondering who to
>blame for the mess.
>
>I'm less interested in blame, but I do think we need to get
>people's reasoned and considered opinions about what the
>right technical thing to do is, as far as state management,
>in light of both deployed code and also the working group's
>previous stand.

	I agree (for what it's worth 8-) that with the -05 draft
now an RFC, more discussion is needed before making a knee-jerk
change.

	The RCF is excellent w.r.t. the Version 1 cookie spec.
It's "historical" section politely gets across that Version 0
cookies were not developed with sound use of MIME header design
and parsing principles, and provides enough information for
others to attempt reverse engineering a parser for those.
Obviously, a reverse engineered parser for those will need
field testing to become adequately reliable with the Set-Cookie
headers currently encountered in the real world.

	All that's really needed there is to clarify the apparent
suggestion that  ; $PATH=foo ; $DOMAIN=blah  be appended to Version
0 Cookie request headers, and make clear that the date format for
the expires attribute value need not be as stated in the Netscape
spec.  Here's another reverse engineering tip in that regard.
Apparently, the Netscape ad hoc parser does not require an '='
between the expires name and value, so you can encounter Set-Cookie
headers that were sent without it.  That's easy enough to deal with
if the developer has been warned.

	W.r.t. making Version 1 cookies "backward compatible", it
should be stated that Netscape's parser uses the first cookie in
an apparent series.  It's too late to cope with that in MicroSoft's
reverse engineered parser, but they've indicated that they plan to
take that into account in a subsequent MSIE version.

	One possibliity is to exclude, formally, expires (case
insensitive) as an acceptible cookie name for Version 1 cookies.
max-age should still be required for setting expirations.  I
don't know if there is a way to indicate this cleanly in a spec,
but then once the valid Version 1 cookie were processed by a
Version 1 aware agent, on encountering the expires string where
a cookie name was expected, it would be ignored, and the unquoted
despite spaces stuff that follows could be dealt with as is being
done for the reverse engineered parsing of Version 0 expires
attributes, but ignored.  The older agents, instead, would actually
use it.

	It can be done.  It's simply of question of whether what
needs to be done can be specified in a way that's acceptible for
an IETF Standards Track spec.

				Fote

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

Received on Wednesday, 26 February 1997 14:40:21 UTC