Re: cookies: 2/4 headers?

Foteos Macrides <MACRIDES@SCI.WFBR.EDU> wrote:
  > 	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 just looked at Koen's message, and I see no semantic difference between
Cookie-Control and Set-Cookie2.
  > 
  > 	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.

I outlined my reasons earlier today.  I admit they're not show-stoppers.
  > 
  > 	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. :) :)

The State Mgmt discussions were originally conducted by a sub-group
until we reached enough of a consensus to put together I-D's to present
to http-wg, because it's much easier to keep the discussion focussed if
there's a specific proposal to discuss (by a large group).  The
discussion of 2/4 headers was meant for that sub-group alone, but it
got leaked, alas.  My intent had been to hash the details out there
before getting the WG involved, but things didn't work out that way.
If it had gotten rejected there, we wouldn't have had any noise about
it on http-wg.  Sigh.

Dave Kristol

The URL you cite above is the place to find all the *public* evolutionary documents,
even the not-yet-I-D public ones.  (2-36-2.42 was meant to be private,
which is why you don't see it listed on that page.)

Received on Monday, 3 March 1997 11:53:52 UTC