Re: [http-state] http-state charter
Bil Corry <bil@corry.biz> Thu, 30 July 2009 18:46 UTC
Return-Path: <bil@corry.biz>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 73A963A6C63 for <http-state@core3.amsl.com>; Thu, 30 Jul 2009 11:46:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.951
X-Spam-Level:
X-Spam-Status: No, score=-3.951 tagged_above=-999 required=5 tests=[AWL=-2.216, BAYES_00=-2.599, HELO_MISMATCH_COM=0.553, HOST_MISMATCH_NET=0.311]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ADL2Czbgvdgg for <http-state@core3.amsl.com>; Thu, 30 Jul 2009 11:46:49 -0700 (PDT)
Received: from mail.mindio.com (app1.bc.anu.net [193.189.141.126]) by core3.amsl.com (Postfix) with ESMTP id 713E83A6BC1 for <http-state@ietf.org>; Thu, 30 Jul 2009 11:46:48 -0700 (PDT)
Received: from [127.0.0.1] (unknown [98.212.72.151]) by mail.mindio.com (Postfix) with ESMTP id 509F8FC49A; Thu, 30 Jul 2009 13:46:48 -0500 (CDT)
Message-ID: <4A71EA90.8010908@corry.biz>
Date: Thu, 30 Jul 2009 13:46:40 -0500
From: Bil Corry <bil@corry.biz>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: Daniel Stenberg <dast@haxx.se>
References: <4A70D2D2.9050900@corry.biz> <Pine.LNX.4.62.0907292332310.3168@hixie.dreamhostps.com> <alpine.DEB.2.00.0907301253110.3237@yvahk2.pbagnpgbe.fr>
In-Reply-To: <alpine.DEB.2.00.0907301253110.3237@yvahk2.pbagnpgbe.fr>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
Cc: "http-state@ietf.org" <http-state@ietf.org>
Subject: Re: [http-state] http-state charter
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/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: Thu, 30 Jul 2009 18:46:50 -0000
Daniel Stenberg wrote on 7/30/2009 5:54 AM: > On Wed, 29 Jul 2009, Ian Hickson wrote: > >> (We wouldn't want to finish writing this spec only to find that while >> we were at it, the browser vendors got together and added a new >> feature like httpOnly without it getting into the spec.) > > I agree. httpOnly might be the perfect example as well, as something > that isn't in any spec anywhere (apart from Microsoft's) but is in wide > use already. I added "Add features that are already widely implemented or have a critical mass of support" -- does that work? I also added two more considerations. Revised charter below. - Bil ----- Charter: HTTP State Management Mechanism (http-state) WG Last Modified: 2008-07-30 Mailing Lists: General Discussion: http-state@ietf.org To Subscribe: https://www.ietf.org/mailman/listinfo/http-state Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html Description of Working Group: The HTTP State Management Mechanism (Cookies) was original created by Netscape Communications in their Netscape cookie specification, from which a formal specification followed (RFC 2109, RFC 2965). Due to years of implementation and extension, several ambiguities have become evident, impairing interoperability and the ability to easily implement and use HTTP State Management Mechanism. The working group will refine RFC2965 to: * Incorporate errata and updates * Clarify conformance requirements * Remove known ambiguities where they affect interoperability * Clarify existing methods of extensibility * Remove or deprecate those features that are not widely implemented and also unduly affect interoperability * Add features that are already widely implemented or have a critical mass of support * Where necessary, add implementation advice * Document the security properties of HTTP State Management Mechanism and its associated echanisms for common applications In doing so, it should consider: * Implementer experience * Demonstrated use of HTTP State Management Mechanism * Impact on existing implementations and deployments * Ability to achieve broad implementation. * Ability to address broader use cases than may be contemplated by the original authors. The Working Group's specification deliverables are: * A document that is suitable to supersede RFC 2965 * A document cataloguing the security properties of HTTP State Management Mechanism Goals and Milestones: TBD No Current Internet-Drafts No Request For Comments
- [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Ian Hickson
- Re: [http-state] http-state charter Prasad Shenoy
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Ian Hickson
- Re: [http-state] http-state charter =JeffH
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Dan Winship
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Dan Winship
- Re: [http-state] http-state charter Ian Hickson
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Peter Saint-Andre
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Adam Barth
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Julian Reschke
- Re: [http-state] http-state charter Pascal Gaudette
- Re: [http-state] http-state charter Mark Nottingham
- Re: [http-state] http-state charter Bil Corry
- Re: [http-state] http-state charter Daniel Stenberg
- Re: [http-state] http-state charter Dan Winship
- Re: [http-state] http-state charter Mark Nottingham