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