W3C home > Mailing lists > Public > ietf-http-wg-old@w3.org > January to April 1997

Re: cookies: 2/4 headers?

From: Foteos Macrides <MACRIDES@sci.wfbr.edu>
Date: Mon, 03 Mar 1997 13:51:29 -0500 (EST)
To: dmk@research.bell-labs.com
Cc: http-wg@cuckoo.hpl.hp.com
Message-Id: <01IG2GFKVEWI00FYOX@SCI.WFBR.EDU>
dmk@research.bell-labs.com (Dave Kristol) wrote:
>koen@win.tue.nl (Koen Holtman) wrote:
>  > >>[masinter@parc.xerox.com]
>  > >>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.
>  > >
>  > >[DMK]
>  > >Strangely enough, I was having similar thoughts. 
>  > 
>  > I think that `cookie' is more mainstream than `state' at this point.
>  > 2^N end users have seen the word `cookie' in a popup and/or article.
>
>True, although that's a user-interface issue and need not change if the
>header name changes.  Anyway, it's not unreasonable for Larry to ask
>the question.
>  > 
>  > > 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.
>  > 
>  > Please tell me: do you want to 
>  >  1) completely revise a proposed standard
>  >  2) fix a bug in the downwards compatibility scheme of a proposed
>  >     standard
>  > 
>  > I find you leaning towards 1), which will require a new last call as
>  > far as I am concerned. <---[intended to be provocative!]
>  > 
>  > I would rather do 2).  I want the state-mgmt standard to replace the
>  > `NS cookie preliminary specification ad-hoc standard' as soon as
>  > possible.
>
>Yes, (1) would probably deserve a new last call, but I'm certainly no
>expert on procedure.
>
>I would prefer (2).  Maybe I got too exuberant with the idea of fixing
>some warts in the current spec.  They bother me.  In any case, it's not
>my place to decide either way unilaterally.

	If this discussion leads to consensus that a distinct reply
header for Version 1 cookies is required, please reconsider Koen's
original suggestion --  Cookie-Control  -- which seems semantically
more clean than Set-Cookie2 (or Set-Cookie-V1).

	I don't see why the request header can't remain Cookie.
If the server sent both Cookie-Control and Set-Cookie headers, it
should also be able to handle both Version 1 and Version 0 Cookie
headers based on the presence or absence of a lead $Version=1.  If
the server did send both, the UA will use (a) Version 1 cookie(s)
if it's capable, otherwise a Version 0 cookie.  If the server sent
only a Set-Cookie header (presumeably, based on the revision, without
a Version=1), all UAs will use a Version 0 cookie.  This seems more
likely to get the original, ad hoc cookie scheme replaced, eventually,
by the new IETF State Management scheme.

	Is it possible to keep all of your documents related to
cookies and State Management accessible via one, generic URL, e.g.,
http://portal.research.bell-labs.com/~dmk/cookie.html, and to keep
all of the discussion about possible revisions of RFC 2109 within
this WG, rather than split between here and some sub-group?  This
might help avoid snafus. :) :)

				Fote

=========================================================================
 Foteos Macrides            Worcester Foundation for Biomedical Research
 MACRIDES@SCI.WFBR.EDU         222 Maple Avenue, Shrewsbury, MA 01545
=========================================================================
Received on Monday, 3 March 1997 10:56:31 EST

This archive was generated by hypermail pre-2.1.9 : Wednesday, 24 September 2003 06:32:30 EDT