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

From: =JeffH <[email-masked]>
Date: Fri, 07 Aug 2009 15:36:50 -0700

inline charter edits offered below. am assuming first order task of proposed WG 
is to concoct cookie specification matching current actual practice, and 
second-order is to consider new capabilities/features for follow-on 
specifications. (best viewed in fixed-pitch font)

=JeffH
PayPal InfoSec Team
-------------------

in <http://www.ietf.org/mail-archive/web/http-state/current/msg00051.html>
Bil Corry wrote:
 >
 > Charter: HTTP State Management Mechanism (http-state) WG
 >
 > Last Modified: 2008-07-31
 >
 > 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 (backup)
Archive: http://groups.google.com/group/http-state

 > Description of Working Group:
 >
 > The HTTP State Management Mechanism (Cookies) was original created
 > by Netscape Communications in their  Netscape cookie specification  ,
                                       ^                              ^
                                    informal           ("cookie_spec.html"),

 > from which a formal specification followed (RFC 2109, RFC 2965).

from which formal specifications evolved (RFC 2109, RFC 2965).

 > However, the formal specification was never implemented in practice;

However, the formal specifications were never fully implemented in practice, 
with RFC 2109, in addition to cookie_spec.html, more closely resembling reality 
even though RFC 2965 officially obsoletes the former.

 > Cookie implementation evolved ad-hoc, creating a disparity between
 > the formal specification and real-world usage.

Cookie implementations have evolved in an ad-hoc fashion, creating a disparity 
between the specifications and real-world usage.

 > The working group will create a new RFC that obsoletes RFC 2965 and
 > specifies Cookies as they are used in existing implementations and
 > deployments.

[new para after above]

Accurately specifying existing practice -- on the standards track -- is of 
interest to the HTTP community e.g. because it is quite difficult to create a 
new HTTP User Agent implementation with cookie support due to there being no 
extant accurate HTTP cookie specification. Of course interoperability suffers 
in such a situation.

With respect to further evolving the http state management facility to have new 
features not yet widely implemented and deployed in practice, this working 
group will consider such proposals in the context of further follow-on 
specifications if there is are sufficient resources to do so.

 > In doing so, the working group 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.

I'm a bit leery of the last bullet item. Is it there to allow for "httpOnly" 
flag to be added?

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

 > * Netscape Cookie Specification
 >     http://curl.haxx.se/rfc/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
 > * Widely Implemented - HTTPOnly
 >     http://www.owasp.org/index.php/HTTPOnly

The following I-Ds are examples of desired capabilities and features to 
consider for follow-on specification work:

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

 >
 > Goals and Milestones:
 > TBD
 >
 >
 > No Current Internet-Drafts
 > No Request For Comments

---

From: Leif Johansson <[email-masked]>
Date: Sat, 8 Aug 2009 16:12:50 +0200

> >     http://tools.ietf.org/html/draft-broyer-http-cookie-auth
There are other places where http state management is used but where the
"cookie" is
consumed by the http layer itself rather than the web application. For
instance the re-
authentication "cookie" from
http://tools.ietf.org/html/draft-johansson-http-gss-05.

Does it make sense for the charter to cover such cases?

   Cheers Leif

---

From: Bil Corry <[email-masked]>
Date: Mon, 10 Aug 2009 15:35:57 -0500

=JeffH wrote on 8/7/2009 5:36 PM: 
> inline charter edits offered below. am assuming first order task of
> proposed WG is to concoct cookie specification matching current actual
> practice, and second-order is to consider new capabilities/features for
> follow-on specifications. (best viewed in fixed-pitch font)

Thank you for the suggestions, I've (mostly) incorporated them.  Below is the latest draft of the charter -- 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.  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.

Thoughts?

- Bil

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

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.

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.
This will also allow existing implementations to improve
interoperability if they so choose.

* cookie_spec.html - Netscape Cookie Specification
    http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html

Goals and Milestones:
TBD

---

From: Julian Reschke <[email-masked]>
Date: Mon, 10 Aug 2009 22:42:54 +0200

Bil Corry wrote:
> ...

Yes, I think this is the right approach. Start with the smallest charter 
you can get away with and focus on that. Once you have delivered, 
consider re-chartering the working group.

BR, Julian

---

From: Bil Corry <[email-masked]>
Date: Mon, 10 Aug 2009 16:16:52 -0500

> Does it make sense for the charter to cover such cases?

Once the WG tackles new functionality, we could visit it then.  Until then, the above draft (or similar drafts) would need to achieve widespread implementation before it would fall into the scope of the WG.

- Bil