Subject: [http-state] WG Review: HTTP State Management Mechanism (httpstate)

From: IESG Secretary <[email-masked]>
Date: Tue, 24 Nov 2009 10:00:02 -0800 (PST)

A new IETF working group has been proposed in the Applications Area.  The
IESG has not made any determination as yet.  The following draft charter
was submitted, and is provided for informational purposes only.  Please
send your comments to the IESG mailing list ([email-masked]) by Tuesday,
December 1, 2009.

HTTP State Management Mechanism (httpstate) 
---------------------------------------------------
Current Status: Proposed Working Group
Last modified: 2009-11-11

Chair(s):
  TBD

Applications Area Director(s):
  Lisa Dusseault <[email-masked]>
  Alexey Melnikov <[email-masked]>

Applications Area Advisor:
  Lisa Dusseault <[email-masked]>

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 varying behaviors among real-world implementations.  

The working group will create a new RFC that obsoletes RFC 2109 and 
specifies Cookies as they are actually used in existing implementations 
and deployments.  Where differences exist among the most commonly used 
implementations, the working group will document the variations.  Where 
consensus exists among the most commonly used implementations, the 
working group will specify the consensus behavior.  

The working group must not introduce any new syntax or new semantics 
not already in common use.  

The working group's specific deliverables are: 

* A standards-track document that is suitable to supersede RFC 2109 
(likely based on draft-abarth-cookie) 
* An informational document cataloguing the differences between major 
implementations  In doing so, the working group should consider:  
* cookie_spec.html - Netscape Cookie Specification  
http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsre
f/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  

Goals and Milestones: 
 
Jan 2010 - Feature-complete Internet-Draft of Cookie specification 
Mar 2010 - Feature-complete test suite of Cookie specification 
May 2010 - First fully conforming implementation in a major browser 
Jul 2010 - Last Call for Cookie specification 
Sep 2010 - Second fully conforming implementation in a major browser 
Nov 2010 - Submit Cookie specification to IESG for consideration as 
           a Draft Standard 
Nov 2010 - Submit deviation description to IESG for consideration as 
           Informational

---

From: David Morris <[email-masked]>
Date: Wed, 25 Nov 2009 00:15:03 -0800 (PST)

I'm in favor of the proposed WG (and will participate) .. but I seriously 
doubt the proposed schedule. I've tried to find a schedule discussion in 
the archive and failed. Getting the process approved and running w/o 
having the Chair identified over the holiday season with a feature
complete draft in 10 weeks doesn't seem possible. I'd find a couple months 
longer more realistic.

Dave Morris

On Tue, 24 Nov 2009, IESG Secretary wrote:

>  Archive: http://www.ietf.org/mail-archive/web/http-state/current/maillist.html
> _______________________________________________
> IETF-Announce mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 05:56:11 -0800

We can push the schedule out a couple of months if you like, but we're
actually quite close to a feature-complete draft:

http://tools.ietf.org/id/draft-abarth-cookie-05.txt (just posted,
doesn't seem to be quite live yet)

Of course, there's still a bunch of work to do to make the features
correct, but at least we've got all the sections filled in.

Adam

On Wed, Nov 25, 2009 at 12:15 AM, David Morris <[email-masked]> wrote:
> doubt the proposed schedule. I've tried to find a schedule discussion in the
> archive and failed. Getting the process approved and running w/o having the
> Chair identified over the holiday season with a feature
>>  Archive:
>> http://www.ietf.org/mail-archive/web/http-state/current/maillist.html
> http-state mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/http-state
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 25 Nov 2009 15:06:32 -0700

I support the formation of a new working group in this area. I have a few concerns about the charter:

> cookie_spec.html, more closely resemble real-world implementations 
> than RFC 2965, even though RFC 2965 officially obsoletes the former.
> specifies Cookies as they are actually used in existing 
> implementations and deployments.  Where differences exist among the 
> most commonly used implementations, the working group will document 
> the variations.  Where consensus exists among the most commonly used 
> implementations, the working group will specify the consensus behavior.

Shouldn't the new RFC at least update RFC 2965? I think it will cause confusion. At the very least I would like to see the new work explain its relationship to RFC 2965.

> not already in common use.

Does the existing syntax already in common use sufficient to correct the known interoperability issues this effort is trying to address? Do people feel they have enough tools within the boundaries of this restriction to improve interoperability?

> http://web.archive.org/web/20070805052634/http://wp.netscape.com/newsref/std/cookie_spec.html

I find the timeline to be too aggressive in its first deliverable. Even if the document is almost ready, getting the working group setup and allowing people time to review the documents will take time. A couple of months would be enough.

I would also like to see more detailed milestones for the informational RFC as it will serve as the primary knowledge base container for the WG.

EHL

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 14:21:58 -0800

On Wed, Nov 25, 2009 at 2:06 PM, Eran Hammer-Lahav <[email-masked]> wrote:
> Shouldn't the new RFC at least update RFC 2965? I think it will cause confusion.
> At the very least I would like to see the new work explain its relationship to
> RFC 2965.

We discussed this on the mailing list a bit.  The general feeling was
that RFC 2965 represents an incremental step toward a second version
of the cookie protocol, perhaps along the lines of
draft-pettersen-cookie-v2.  Our goal is to produce a specification of
the "first" version of the cookie protocol.  We explicitly want to
leave all v2 work for after a re-charter.

> Does the existing syntax already in common use sufficient to correct the known
> interoperability issues this effort is trying to address?

I suppose that hinges on what "common use" means.  My reading of this
means some majority of browser market share.  For example...

1) IE + Firefox + (Chrome or Safari or Opera)
2) Every non-IE browser + a reason sufficiently compelling to convince
IE to adopt

If IE and Firefox disagree and there isn't a clear reason for
preferring one or the other, we'll be in trouble.

In general, the major implementations appear to be fairly
interoperable.  The interoperability issues arise with smaller market
share implementations or new entrants that have not yet been
ruthlessly beat into conformance via trial and error.

> Do people feel they have
> enough tools within the boundaries of this restriction to improve interoperability?

The benefit of having this strong restriction in the charter is to
prevent us from adding additional scope to our work.  Although we
might be tempted to improve various aesthetic  or other aspects of the
protocol, placing those activities strictly outside the charter will
help us remain on task.

> I find the timeline to be too aggressive in its first deliverable. Even if the document
> is almost ready, getting the working group setup and allowing people time to review
> the documents will take time. A couple of months would be enough.

Sounds like we should push out the schedule two months.

> I would also like to see more detailed milestones for the informational RFC as it will
> serve as the primary knowledge base container for the WG.

I suspect the primary knowledge base contains for the WG will be our
test suite.  I'd like to have a test before making any testable change
to the draft.  So far, I've been able to keep this up expect for the
date parsing algorithm, which I haven't figured out a good way to test
yet.

Adam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 25 Nov 2009 16:00:08 -0700

> -----Original Message-----
> From: Adam Barth [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2009 2:22 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; [email-masked]
> Subject: Re: [http-state] WG Review: HTTP State Management Mechanism
> (httpstate)
> 
> > At the very least I would like to see the new work explain its
> > relationship to RFC 2965.
> 
> We discussed this on the mailing list a bit.  The general feeling was that RFC
> 2965 represents an incremental step toward a second version of the cookie
> protocol, perhaps along the lines of draft-pettersen-cookie-v2.  Our goal is to
> produce a specification of the "first" version of the cookie protocol.  We
> explicitly want to leave all v2 work for after a re-charter.

That's fine and perfectly reasonable. My comment is that this arrangement will create an odd combination of two RFCs obsoleting 2109 but without offering any clarity on their relationship. If the new work updates 2965 to the extent that it clarifies this, it will make it easier to follow. In other words, it will state that 2965 doesn't make the "first" version obsolete anymore.

> > Does the existing syntax already in common use sufficient to correct
> > the known interoperability issues this effort is trying to address?
> 
> 2) Every non-IE browser + a reason sufficiently compelling to convince IE to
> adopt
> 
> If IE and Firefox disagree and there isn't a clear reason for preferring one or
> the other, we'll be in trouble.

I just want to make sure you have the right tools to accomplish what you set to do. If you are comfortable with this, I have no problems with it. We can always re-charter if we get "in trouble".

> In general, the major implementations appear to be fairly interoperable.  The
> interoperability issues arise with smaller market share implementations or
> new entrants that have not yet been ruthlessly beat into conformance via
> trial and error.
> 
> > Do people feel they have
> The benefit of having this strong restriction in the charter is to prevent us
> from adding additional scope to our work.  Although we might be tempted to
> improve various aesthetic  or other aspects of the protocol, placing those
> activities strictly outside the charter will help us remain on task.

Yes, no need for bikeshedding.

> > I find the timeline to be too aggressive in its first deliverable.
> > Even if the document is almost ready, getting the working group setup
> > and allowing people time to review the documents will take time. A couple
> of months would be enough.
> 
> > I would also like to see more detailed milestones for the
> > informational RFC as it will serve as the primary knowledge base container
> for the WG.
> 
> I suspect the primary knowledge base contains for the WG will be our test
> suite.  I'd like to have a test before making any testable change to the draft.
> So far, I've been able to keep this up expect for the date parsing algorithm,
> which I haven't figured out a good way to test yet.

My point is that you have detailed milestone and then without any explicit preparation, an informational RFC submission. I would like to see how the progression of this RFC is planned.

EHL

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 16:20:59 -0800

> That's fine and perfectly reasonable. My comment is that this arrangement will create an odd combination of two RFCs obsoleting 2109 but without offering any clarity on their relationship. If the n…

Yngve was the most vocal about not obsoleting 2965, so I'll let him
respond.  For my part, I'd be fine with obsoleting it.

> My point is that you have detailed milestone and then without any explicit preparation, an informational RFC submission. I would like to see how the progression of this RFC is planned.

Fair enough.  I've pushed an updated version of the charter with the
following two changes:

http://github.com/abarth/http-state/blob/master/admin/charter.txt

1) I've added milestones for the deviation description document.
2) I've pushed out the entire schedule two months.

Bil, do the milestones for the deviation description document look
reasonable to you?  (For those new to the list, Bil had expressed
interest in editing that document.)

Adam

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 25 Nov 2009 17:36:11 -0700

> Sent: Wednesday, November 25, 2009 4:21 PM
> To: Eran Hammer-Lahav
> Cc: [email-masked]; [email-masked]; Yngve N. Pettersen; Bil Corry
> > That's fine and perfectly reasonable. My comment is that this arrangement
> will create an odd combination of two RFCs obsoleting 2109 but without
> offering any clarity on their relationship. If the new work updates 2965 to the
> extent that it clarifies this, it will make it easier to follow. In other words, it
> will state that 2965 doesn't make the "first" version obsolete anymore.
> 
> Yngve was the most vocal about not obsoleting 2965, so I'll let him respond.
> For my part, I'd be fine with obsoleting it.

There is a middle ground of 'Updating' it.

> > My point is that you have detailed milestone and then without any explicit
> preparation, an informational RFC submission. I would like to see how the
> progression of this RFC is planned.
> 

Thanks.

> reasonable to you?  (For those new to the list, Bil had expressed interest in
> editing that document.)
> 
> Adam

---

From: "Yngve N. Pettersen (Developer Opera Software ASA)" <[email-masked]>
Date: Thu, 26 Nov 2009 02:09:10 +0100

On Thu, 26 Nov 2009 01:20:59 +0100, Adam Barth <[email-masked]> wrote:

>> That's fine and perfectly reasonable. My comment is that this  
>> arrangement will create an odd combination of two RFCs obsoleting 2109  
>> but without offering any clarity on their relationship. If the new work  
>> updates 2965 to the extent that it clarifies this, it will make it  
>> easier to follow. In other words, it will state that 2965 doesn't make  
>> the "first" version obsolete anymore.
>

My arguments were, as I recall along these lines:

  - RFC 2965 defines a new header, Set-Cookie2, as such it is defining a  
new protocol.

  - There are issues with cookies, particularly the domain attribute  
handling, that will require an updated cookie specification. RFC 2965  
currently offers the best framework for doing that. If 2965 is obsoleted  
we would either have to reintroduce the syntax (and still maintain  
backward compatibility to 2965), or create a new header, e.g. Set-Cookie3,  
which is at least going to look odd.

  - The new spec is only intended to document Netscape cookies + later  
extensions, which is actually pre-2109, but mostly included in 2109,  
expect for the extended syntax, and will mostly avoid RFC 2965's area.

RFC 2965 does overlap on the Cookie header, but that overlap is limited,  
and does not IMO make it necessary to obsolete the spec because those  
extensions are (reasonably) within the exisiting syntax of the Netscape  
Cookie spec.

As I said earlier: One way to think about it is that if Netscape cookies  
are v0.1 (just to keep with the 2965 version numbering), 2965 cookies are  
v1.0, then the proposed document might be considered v0.5, on a different  
branch/fork of the cookie specification.

To further emphasize the point: A vendor (usually, at least) does not  
obsolete v5.x of a complex product even if he have to ship a v4.y to  
handle some problems for customers that are currently not able to upgrade  
to the most recent version (there are, as I am sure all of you are aware,  
quite a few products that have that kind of update process, particularly  
Operating Systems).

I suspect that this is not the first time that the IETF have had to update  
an older version of a protocol, while there is a newer version that  
obsoletes the version being updated. If that is so, does the IESG  
recollect what was done in those situations?

My suggestion would be, if we are even going to mention 2965 in the new  
document, to just say that RFC 2965 specifies a new version of the Cookie  
protocol and is not impacted by the new document, except possibly if the  
Cookie header syntax is clarified, in which case an "updates RFC 2965"  
entry might be in order for those items.

-- 
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: David Morris <[email-masked]>
Date: Wed, 25 Nov 2009 20:08:10 -0800 (PST)

Exactly ... The problems identified and 'addressed' by 2965 are not in the
scope of this working group. Therefore, I would oppose deprecating 2965 
with the currently scheduled work product.

On Thu, 26 Nov 2009, Yngve N. Pettersen (Developer Opera Software ASA) wrote:

>>> offering any clarity on their relationship. If the new work updates 2965 
>>> to the extent that it clarifies this, it will make it easier to follow. In 
>>> other words, it will state that 2965 doesn't make the "first" version 
>>> obsolete anymore.
>> 
> - RFC 2965 defines a new header, Set-Cookie2, as such it is defining a new 
> protocol.
>
> - There are issues with cookies, particularly the domain attribute handling, 
> that will require an updated cookie specification. RFC 2965 currently offers 
> the best framework for doing that. If 2965 is obsoleted we would either have 
> to reintroduce the syntax (and still maintain backward compatibility to 
> 2965), or create a new header, e.g. Set-Cookie3, which is at least going to 
> look odd.
>
> extensions, which is actually pre-2109, but mostly included in 2109, expect 
> for the extended syntax, and will mostly avoid RFC 2965's area.
>
> RFC 2965 does overlap on the Cookie header, but that overlap is limited, and 
> does not IMO make it necessary to obsolete the spec because those extensions 
> are (reasonably) within the exisiting syntax of the Netscape Cookie spec.
>
> As I said earlier: One way to think about it is that if Netscape cookies are 
> v0.1 (just to keep with the 2965 version numbering), 2965 cookies are v1.0, 
> then the proposed document might be considered v0.5, on a different 
> obsolete v5.x of a complex product even if he have to ship a v4.y to handle 
> some problems for customers that are currently not able to upgrade to the 
> most recent version (there are, as I am sure all of you are aware, quite a 
> few products that have that kind of update process, particularly Operating 
> Systems).
>
> I suspect that this is not the first time that the IETF have had to update an 
> older version of a protocol, while there is a newer version that obsoletes 
> the version being updated. If that is so, does the IESG recollect what was 
> done in those situations?
>
> Cookie header syntax is clarified, in which case an "updates RFC 2965" entry 
> might be in order for those items.
>
> -- 
> Sincerely,
> Yngve N. Pettersen
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 26 Nov 2009 00:34:24 -0700

Again, I am not suggesting to extend the scope of this WG. All I am saying is that 2965 already declared 2109 obsolete. It would be odd at best to having yet another RFC declare 2109 obsolete. What you need to do is *update* 2965 to clarify that it does not void 2109, but only defined a new mechanism. Then go and clarify 2109.

I think what you are missing here is that a new RFC can either obsolete *or* update an older RFC. This gives you the option to directly address areas where the two specs overlap in their use of the same header, etc. It lets you talk about very specific parts in 2965 without replacing it.

All you need to do is add to the charter the ability to "update RFC 2965 to the extent it overlaps or void 2109". That will limit your scope from dealing with the newer cookie methods.

EHL

> From: Yngve N. Pettersen (Developer Opera Software ASA)
> [mailto:[email-masked]]
> Sent: Wednesday, November 25, 2009 5:09 PM
> To: Adam Barth; Eran Hammer-Lahav
> Cc: [email-masked]; [email-masked]; Bil Corry
> > On Wed, Nov 25, 2009 at 3:00 PM, Eran Hammer-Lahav
> > <[email-masked]>
> > wrote:
> >> arrangement will create an odd combination of two RFCs obsoleting
> >> 2109 but without offering any clarity on their relationship. If the
> >> new work updates 2965 to the extent that it clarifies this, it will
> >> make it easier to follow. In other words, it will state that 2965
> >> doesn't make the "first" version obsolete anymore.
> >
> to reintroduce the syntax (and still maintain backward compatibility to 2965),
> or create a new header, e.g. Set-Cookie3, which is at least going to look odd.
> 
> extensions, which is actually pre-2109, but mostly included in 2109, expect for
> the extended syntax, and will mostly avoid RFC 2965's area.
> 
> does not IMO make it necessary to obsolete the spec because those
> As I said earlier: One way to think about it is that if Netscape cookies are v0.1
> (just to keep with the 2965 version numbering), 2965 cookies are v1.0, then
> the proposed document might be considered v0.5, on a different
> most recent version (there are, as I am sure all of you are aware, quite a few
> products that have that kind of update process, particularly Operating
> Systems).
> 
> older version of a protocol, while there is a newer version that obsoletes the
> version being updated. If that is so, does the IESG recollect what was done in
> those situations?
>

---

From: Adam Barth <[email-masked]>
Date: Wed, 25 Nov 2009 23:39:50 -0800

> All you need to do is add to the charter the ability to "update RFC 2965 to the extent it overlaps or void 2109". That will limit your scope from dealing with the newer cookie methods.

Done.  We can always decide to make a "null" update later in the process.

Adam

---

From: Bil Corry <[email-masked]>
Date: Thu, 26 Nov 2009 01:20:54 -0800

> interest in editing that document.)

Yes, so long as there are not a slew of new tests added to the test suite in May 2010 :)

With the I-D due in March 2010, it will perfectly coincide with Anaheim[1]; we can use Anaheim to finalize the I-D along with working on the test suite and deviation description document.  I know many of us are already planning to attend Anaheim, for those just joining the list, please consider attending.

- Bil

[1] http://www.ietf.org/meeting/upcoming.html