Re: The state of cookies

At 8:38 AM -0800 3/1/97, Larry Masinter wrote:
>This morning, I started having some really bad second
>thoughts about the state of cookies. Here are some
>hard questions (intended to be provocative):
>
>a) if we're not going to be compatible, why call it a "cookie"
>  at all? It's not all that descriptive. "Set-state" and
>   "state", for example.

Strangely enough, I was having similar thoughts.  I agree with your
argument in favor of a change.  The argument in favor of
Set-Cookie2[/Cookie2] is to convey similarity of concept and behavior.

>
>b) if we're not going to be compatible, what's the rush?
>
>   There's no installed base of "Set-Cookie2", so
>   why should we try to revise this quickly?

My reason is personal.  I would like to have finished the specification.

However, if you believe there is merit in having an IETF specification for
cookies, then sooner is better.  I think the arguments for such a
specification are:
	- the new specification is tighter and more likely to yield
interoperable implementations
	- the new specification emphasizes the importance of privacy
protections

>
>c) no-one has expressed an opinion that the new draft is
>   actually technically better than RFC 2109, only that
>   we should do this because of compatibility with some
>   part of the "installed base".

What is "the new draft"? There is no new draft filed with IETF.  I
announced to a sub-group mailing list a draft for their inspection.  I had
not opened up that specification to http-wg.  (Yes, I posted a
state-mgmt-06 draft for people to inspect, but it only included errata to
RFC 2109.  It included none of the more radical changes, like a change of
header names.  And I never sent it to IETF.)
>
>   It's a bad precedent to revise a proposed standard
>   for non-technical reasons, and only because one of
>   the implementors didn't actually read the spec at
>   the right time.

I'll let Yaron Goland argue that one....

>
>
>d) There was some argument initially that the whole idea
>   of cookies was a bad idea. If we reset to proposed, will
>   we need to revisit those arguments, since what we're doing
>   with cookies is no longer a reflection of "running code".

Aren't we still *at* Proposed?  What's to reset?  The delay will be in
seeing two or more interoperating implementations.  Only the vendors can
tell us how long it would take to produce the browsers.


I am not particularly happy at the recent turn of events, but I'm
interested in producing a spec. that will actually get honored, not
ignored.  So I am willing to change the words to produce something people
will use.

Dave Kristol

Received on Saturday, 1 March 1997 14:58:44 UTC