Re: Revising RFC6265 ("Cookies")

On 13/11/2015 1:16 p.m., Mark Nottingham wrote:
> As discussed in Yokohama, we have several proposals for modifying RFC6265 ('Cookies'), including:
> 
>  - https://tools.ietf.org/html/draft-west-leave-secure-cookies-alone 
>  - https://tools.ietf.org/html/draft-west-cookie-prefixes
>  - https://tools.ietf.org/html/draft-west-first-party-cookies
>  - https://tools.ietf.org/html/draft-west-origin-cookies
> 
> Additionally, there are a number of errata against the document:
>   http://www.rfc-editor.org/errata_search.php?rfc=6265
> 
> A few notes:
> 
> * Our Area Director generally supports us taking on work on this specification.
> 
> * Because of the way that Cookies are defined, it's not practical to publish modifications to the algorithms as separate documents; rather, I strongly suspect we need to "open up" the Cookie specification itself to incorporate them.
> 
> * 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.
> 

That was a good approach and it also worked well with the RFC2616 overhaul.



> Keeping all of that that in mind, my current thinking is that we should:
> 
> 1. Select a set of proposals (expressed as Internet Drafts) that
reflect implementation experience
> 2. Once we have consensus on their contents, edit the Cookie
specification itself to incorporate them, as well as the errata
> 3. Upon incorporation, go immediately to WGLC to confirm that the
proposals have been correctly applied.
> 
> The tricky part here is determining what "reflects implementation
experience," because some implementers may be reluctant to adopt a
pre-standard spec, and because some of these proposals require
implementation both on the client and server side
(leave-secure-cookies-alone seeming to be the exception here).
> 
> To aid that, I'd like to treat the Call for Adoption process for
> each
proposal draft as a "call for intent to implement" -- with the idea that
if we see a significant amount of interest by the relevant parties,
that's a good sign for adoption. Then, we can work on the individual
specifications in parallel with that implementation.
> 
> Importantly, we would NOT be taking non-editoral issues on the
> Cookie
spec itself; changes would have to go through the draft proposal process
outlined above.
> 
> Of course, we're not limited to the proposals listed above; if you
have one, please submit a draft soon (or give me a heads up that you'll
be doing so). Likewise, it may be that some of the proposals aren't
ready for standardisation, but might be in the future; we're not limited
to one revision.

> Does this approach make sense to everyone? 

For the most part. However, I think if we take on Cookies. Adding
non-editorial "good idea" improvement changes should not be prohibited
outright.

Instead we should treat the core spec updates the same way proposed for
the drafts. First get implementer agreement that the change is a
feasible idea, and running code out in the 'Net as widely as possible
converted to doing it that way before the document is altered.

So we would both get the "good idea" change happening, and a realistic
transition path that any remaining implementers can follow. ie. no more
pipe dreams. We want real change to improve Cookies. If that does not
happen this time so be it, we will at least not have made things worse
by adding bloat.

It will also allow us the approach of convincing bad behaviors to be
removed from implementations then the core spec to discourage future
reversions.

Amos

Received on Friday, 13 November 2015 03:28:45 UTC