[http-state] taking further cookie discussion to ietf-http-wg list ? (was: "Revising RFC6265"

[=JeffH <[e-mail]>]

Daniel Stenberg <[e-mail]> wrote:
 >
 > FYI, Over in http-wg:
 >
 >    https://lists.w3.org/Archives/Public/ietf-http-wg/2015OctDec/0165.html

Yep -- this was discussed variously at W3C TPAC and IETF in the last couple 
weeks. text of above msg attached below.

At this point, Mark N. aka mnot and Barry Leiba the area director wish to 
have the existing httpbis WG take on this work, rather than re-constitute 
the http-state WG (for the third time :) ..so the work will occur on the 
[e-mail] list going forward.

therefore, I am thinking that we ought to close this http-state@ list to 
further posting and place a final tombstone message here directing folks to 
take any further cookie-related discussion to the http list 
<[e-mail]>

thoughts?

=JeffH

--
From: Mark Nottingham <[e-mail]>
Date: Fri, 13 Nov 2015 11:16:17 +1100
Message-Id: <[e-mail]>
Cc: Mike West <[e-mail]>
To: HTTP Working Group <[e-mail]>
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/