Re: [http-state] http-state charter

[Bil Corry <bil at corry.biz>]

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 at 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