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

=JeffH <Jeff.Hodges@KingsMountain.com> Fri, 13 November 2015 17:22 UTC

Return-Path: <Jeff.Hodges@kingsmountain.com>
X-Original-To: http-state@ietfa.amsl.com
Delivered-To: http-state@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id 9C7DD1B2D33 for <http-state@ietfa.amsl.com>; Fri, 13 Nov 2015 09:22:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.667
X-Spam-Status: No, score=-101.667 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, IP_NOT_FRIENDLY=0.334, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=no
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id ogJurK5PneFc for <http-state@ietfa.amsl.com>; Fri, 13 Nov 2015 09:22:44 -0800 (PST)
Received: from gproxy9-pub.mail.unifiedlayer.com (gproxy9-pub.mail.unifiedlayer.com []) by ietfa.amsl.com (Postfix) with SMTP id 9DB2D1B2D30 for <http-state@ietf.org>; Fri, 13 Nov 2015 09:22:44 -0800 (PST)
Received: (qmail 28582 invoked by uid 0); 13 Nov 2015 17:22:38 -0000
Received: from unknown (HELO CMOut01) ( by gproxy9.mail.unifiedlayer.com with SMTP; 13 Nov 2015 17:22:38 -0000
Received: from box514.bluehost.com ([]) by CMOut01 with id h5NV1r00M2UhLwi015NYBA; Fri, 13 Nov 2015 10:22:37 -0700
X-Authority-Analysis: v=2.1 cv=VOBOwb/X c=1 sm=1 tr=0 a=9W6Fsu4pMcyimqnCr1W0/w==:117 a=9W6Fsu4pMcyimqnCr1W0/w==:17 a=cNaOj0WVAAAA:8 a=f5113yIGAAAA:8 a=ieNpE_y6AAAA:8 a=IkcTkHD0fZMA:10 a=XYUc-DgfXtMA:10 a=WCh9s9hFB9MA:10 a=qtqOOiqGOCEA:10 a=SSmOFEACAAAA:8 a=wvn1p7I7AAAA:8 a=1XWaLZrsAAAA:8 a=48vgC7mUAAAA:8 a=BqEg4_3jAAAA:8 a=Mg_JdbHG26Cx75kWQBsA:9 a=QEXdDO2ut3YA:10 a=_y2VoykNAd8A:10 a=mhd2NDuUijAA:10
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=kingsmountain.com; s=default; h=Content-Transfer-Encoding:Content-Type:MIME-Version:Date:Message-ID:Cc:To:Subject:From; bh=Wio/e4MPmge8yWePrcgTUW6f3d5qv5RR+2h1RttgQ0w=; b=yvOlq5QPJtMyKFSRQ6UA+nKZwvS4PwfQQa7Q3rhCmhThyrZsogXlk8WYuTmMl6ejHR5fDDQNpDvi4PkBV2vk3lkyB+/hj+DM6vtC443jwMmpI3S90evm/MrOJOU3VbFD;
Received: from [] (port=4737 helo=[]) by box514.bluehost.com with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <Jeff.Hodges@KingsMountain.com>) id 1ZxI3S-0007Yo-AZ; Fri, 13 Nov 2015 10:22:30 -0700
From: =JeffH <Jeff.Hodges@KingsMountain.com>
To: HTTP State <http-state@ietf.org>
Message-ID: <56461C4C.2040606@KingsMountain.com>
Date: Fri, 13 Nov 2015 09:22:20 -0800
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Identified-User: {11025:box514.bluehost.com:kingsmou:kingsmountain.com} {sentby:smtp auth authed with jeff.hodges+kingsmountain.com}
Archived-At: <http://mailarchive.ietf.org/arch/msg/http-state/V4NNvNqxQyYBM1oZlXDSd2a5LY0>
Cc: Mark Nottingham <mnot@mnot.net>, Barry Leiba <barryleiba@computer.org>
Subject: [http-state] taking further cookie discussion to ietf-http-wg list ? (was: "Revising RFC6265"
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/http-state/>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Nov 2015 17:22:46 -0000

Daniel Stenberg <daniel@haxx.se>; 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 
ietf-http-wg@w3.org 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 



From: Mark Nottingham <mnot@mnot.net>;
Date: Fri, 13 Nov 2015 11:16:17 +1100
Message-Id: <FAF2C2E8-0A6A-4C34-B4C4-57190AAE118D@mnot.net>;
Cc: Mike West <mkwst@google.com>;
To: HTTP Working Group <ietf-http-wg@w3.org>;
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:

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 

* 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 

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?


Mark Nottingham https://www.mnot.net/