Subject: Re: [http-state] comments on http-state charter

From: =JeffH <[email-masked]>
Date: Mon, 17 Aug 2009 16:03:30 -0700

Bil Corry wrote on Mon, 10 Aug 2009 15:35:57 -0500 (13:35 PDT):

 > Thank you for the suggestions, I've (mostly) incorporated them. Below is the
 >  latest draft of the charter --

super, thanks.

 > I've purposely left off the WG task of
 > creating new features for cookies and instead made the focus of the WG to
 > only document existing cookie behavior. This is based on the feedback I've
 > seen so far and I think it'll help keep us from getting distracted.

agreed.

 > Also, I
 > think it'll be challenging to add new features until we have a spec that
 > enumerates existing behavior. However, rather than having to form the WG
 > again to address new features, we could allow the WG to elect to tackle new
 > features at a future date -- perhaps after the bulk of the work for the
 > primary task is completed.

yes, the working group can be re-chartered at a later date.

minor comments on the latest charter draft below.

thanks,

=JeffH

 > Charter: HTTP State Management Mechanism (http-state) WG
 >
 > Last Modified: 2008-08-10
 >
 > Mailing Lists:
 > General Discussion: [email-masked]
 > To Subscribe: https://www.ietf.org/mailman/listinfo/http-state
 > Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html
 > Alternative Archive: http://groups.google.com/group/http-state
 >
 > Description of Working Group:
 >
 > The HTTP State Management Mechanism (aka Cookies) was originally
 > created by Netscape Communications in their informal Netscape cookie
 > specification ("cookie_spec.html"), from which formal specifications
 > RFC 2109 and RFC 2965 evolved.  The formal specifications, however,
 > were never fully implemented in practice; RFC 2109, in addition to
 > cookie_spec.html, more closely resemble real-world implementations
 > than RFC 2965, even though RFC 2965 officially obsoletes the former.
 > Compounding the problem are undocumented features (such as HTTPOnly),
 > and widely varying behaviors among real-world implementations.
                                                                ^
cite..

   http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies

..here?

 > The working group will create a new RFC that obsoletes RFC 2965 and
 > specifies Cookies as they are actually used in existing
 > implementations and deployments.  Where differences exist among the
 > most common implementations, the working group will document the
 > variations and provide a recommended choice for new implementations.
                                                  ^
                                           updates and

 > This will also allow existing implementations to improve
                  ^^^^^
               facilitate

 > interoperability if they so choose.
 >
 > The following specifications, RFCs and Internet-Drafts should be
                                ^
                             documents,
 > considered:
 > * cookie_spec.html - Netscape Cookie Specification
 > 
http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html

   * Browser Security Handbook
       http://code.google.com/p/browsersec/wiki/Main

 > * RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965)
 >     http://tools.ietf.org/html/rfc2109
 > * RFC 2964 - Use of HTTP State Management
 >     http://tools.ietf.org/html/rfc2964
 > * RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109)
 >     http://tools.ietf.org/html/rfc2965
 > * Widely Implemented - HTTPOnly
 >     http://www.owasp.org/index.php/HTTPOnly
 >
 > Goals and Milestones:
 > TBD

---
end

---

From: Bil Corry <[email-masked]>
Date: Tue, 18 Aug 2009 20:50:01 -0500

> minor comments on the latest charter draft below.

Thanks, below is the current draft.  Additional feedback welcome.

- Bil

Last Modified: 2009-08-18

Mailing Lists:

The working group will create a new RFC that obsoletes RFC 2965 and
specifies Cookies as they are actually used in existing
implementations and deployments.  Where differences exist among the
most common implementations, the working group will document the
variations and provide a recommended choice for updates and new 
implementations.  This will also facilitate interoperability among
existing implementations if they so choose.

The following specifications, RFCs, Internet-Drafts and documents
should be considered:

* cookie_spec.html - Netscape Cookie Specification
    http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html
* RFC 2109 - HTTP State Management Mechanism (Obsoleted by RFC 2965)
    http://tools.ietf.org/html/rfc2109
* RFC 2964 - Use of HTTP State Management
    http://tools.ietf.org/html/rfc2964
* RFC 2965 - HTTP State Management Mechanism (Obsoletes RFC 2109)
    http://tools.ietf.org/html/rfc2965
* I-D - HTTP State Management Mechanism v2
    http://tools.ietf.org/html/draft-pettersen-cookie-v2
* I-D - Cookie-based HTTP Authentication
    http://tools.ietf.org/html/draft-broyer-http-cookie-auth
* Widely Implemented - HTTPOnly
    http://www.owasp.org/index.php/HTTPOnly
* Browser Security Handbook - Cookies
    http://code.google.com/p/browsersec/wiki/Part2#Same-origin_policy_for_cookies
* HTTP Cookies: Standards, Privacy, and Politics by David M. Kristol
    http://arxiv.org/PS_cache/cs/pdf/0105/0105018v1.pdf

---

From: Julian Reschke <[email-masked]>
Date: Wed, 19 Aug 2009 09:45:09 +0200

Bil Corry wrote:
> ...
> ...

Anne correctly mentioned that in RFC2119 terms, "recommended" is the 
same as "RECOMMENDED", which in turn is the same as "SHOULD".

So when the charter say "provide a recommended choice", is this about 
making normative requirements? I think this really needs to be clarified.

BR, Julian

---

From: "Yngve N. Pettersen" <[email-masked]>
Date: Wed, 19 Aug 2009 16:01:00 +0200

On Wed, 19 Aug 2009 03:50:01 +0200, Bil Corry <[email-masked]> wrote:

> implementations and deployments.

I am not sure about this point, *unless* the intention is to include the  
entire RFC 2965 specification (including headers and header syntax) in the  
new specification. If that is the intention, I think it should be spelled  
out, since RFC 2965 defines a different syntax.

-- 
Sincerely,
Yngve N. Pettersen

********************************************************************
Senior Developer                     Email: [email-masked]
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************

---

From: Adam Barth <[email-masked]>
Date: Wed, 19 Aug 2009 08:50:55 -0700

> out, since RFC 2965 defines a different syntax.

I don't think our intention is to support all the features of 2965 in
our first document, just as we're not going to support all the
features of 2109.  Is creating a feature superset required for
obsoleting an RFC?  That would seem to preclude ever removing features
that were not adopted by the marketplace.

Adam