W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2015

Re: Revising RFC6265 ("Cookies")

From: Daniel Stenberg <daniel@haxx.se>
Date: Fri, 13 Nov 2015 09:01:43 +0100 (CET)
To: Mark Nottingham <mnot@mnot.net>
cc: HTTP Working Group <ietf-http-wg@w3.org>, Mike West <mkwst@google.com>
Message-ID: <alpine.DEB.2.11.1511130846120.17326@tvnag.unkk.fr>
On Fri, 13 Nov 2015, Mark Nottingham wrote:

> * Our Area Director generally supports us taking on work on this specification.

I'm very positive to this!

> * Many have argued that RFC6265 was more successful than previous efforts 
> because it restricted itself to documenting current behaviours, rather than 
> speculatively adopting what seems like "good ideas" at the time.

I would agree. Writing down how the world looks is much easier than trying to 
agree on a way how it should be improved. Even though I'll also admit that I 
"lost" a few struggles in that spec on how to describe the current world. =)

Let me also just state some obvious facts about cookies from my perspective.

The by far the biggest challange with changing cookies is that the 
server-sides are very very disparate and have been re-implemented over and 
over again by thousands of developers. It is not an as homogeneous world as it 
is on the client-side where there's a smallish set (in the dozens range or so) 
of clients and libraries that cover a large portion of the users.

Thus, changing cookies is much more work in the server side in lots of custom 
written implementations. Work in this group or in the IETF in general has a 
problem to reach those server side developers.

To me, the most sensible way forward is to change cookies in a way that the 
existing server implementations keep working (mostly) the same and only 
introduce changes that will make cookies better for the ones that adopt the 
news. That will then also avoid us having browsers break popular lagacy sites 
to adopt the new cookie ways.

-- 

  / daniel.haxx.se
Received on Friday, 13 November 2015 08:02:11 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:40 UTC