- From: Mark Nottingham <mnot@mnot.net>
- Date: Fri, 13 Nov 2015 11:16:17 +1100
- To: HTTP Working Group <ietf-http-wg@w3.org>
- Cc: Mike West <mkwst@google.com>
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.
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?
Cheers,
--
Mark Nottingham https://www.mnot.net/
Received on Friday, 13 November 2015 00:16:47 UTC