RE: Comments on the new cookie draft

The issue is backwards compatibility. The current spec is not backwards
compatible and that means that it will not be implemented by content
providers. They are not going to suffer the extra burden of sniffing
user agents. As the goal is to create a standard that will actually be
implemented, we then need to change the standard in order to help ensure
its implementation.


PS Who is going around saying that Microsoft will be making changes to
its cookie support? It certainly isn't anyone who works for Microsoft.

>-----Original Message-----
>From:	Foteos Macrides [SMTP:MACRIDES@SCI.WFBR.EDU]
>Sent:	Wednesday, February 26, 1997 2:34 PM
>Subject:	Re: Comments on the new cookie draft
>Larry Masinter <> 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
>>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
>	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 17:01:58 UTC