The state of cookies

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.

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?

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".

   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.
 

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".


-- 
http://www.parc.xerox.com/masinter

Received on Saturday, 1 March 1997 09:41:28 UTC