Re: [http-state] 'HTTP State Management Mechanism' to Proposed Standard

Adam Barth <> Sun, 06 March 2011 01:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 500FD3A6AC9 for <>; Sat, 5 Mar 2011 17:07:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.636
X-Spam-Status: No, score=-1.636 tagged_above=-999 required=5 tests=[AWL=-1.114, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, FRT_ADOBE2=2.455, RCVD_IN_DNSWL_LOW=-1]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wwR6uytrEStR for <>; Sat, 5 Mar 2011 17:07:55 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 1D3503A6AA1 for <>; Sat, 5 Mar 2011 17:07:55 -0800 (PST)
Received: by ywi6 with SMTP id 6so1494627ywi.31 for <>; Sat, 05 Mar 2011 17:09:06 -0800 (PST)
Received: by with SMTP id l1mr2739938ybg.94.1299373744927; Sat, 05 Mar 2011 17:09:04 -0800 (PST)
Received: from ( []) by with ESMTPS id l10sm704582yha.39.2011. (version=SSLv3 cipher=OTHER); Sat, 05 Mar 2011 17:09:03 -0800 (PST)
Received: by iyj8 with SMTP id 8so3502129iyj.31 for <>; Sat, 05 Mar 2011 17:09:01 -0800 (PST)
Received: by with SMTP id g1mr1710669ibe.193.1299373741847; Sat, 05 Mar 2011 17:09:01 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Sat, 5 Mar 2011 17:03:02 -0800 (PST)
In-Reply-To: <>
References: <> <>
From: Adam Barth <>
Date: Sat, 05 Mar 2011 17:03:02 -0800
Message-ID: <>
To: Larry Masinter <>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: httpstate chair <>, IETF HTTP State WG <>, Internet Architecture Board <>, "" <>
Subject: Re: [http-state] 'HTTP State Management Mechanism' to Proposed Standard
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 06 Mar 2011 01:07:56 -0000

I might be overstepping, but my view is that the difference between
"what we're doing and don't want to change" and "what should be"
became clearer in the intervening years, or at least we (collectively)
have had a lot more experience in telling the two apart.


On Sat, Mar 5, 2011 at 4:45 PM, Larry Masinter <> wrote:
> If you're revisiting history:
> There were a lot of issues raised and settled during the development of HTTP 1.1 in the '90s, but the differences between "what we're doing and don't want to change" and "what should be" over cookies were irreconcilable at the time; 2616 and 2617 got published without cookies, and a separate group went on to publish 2965. I think you could say it was "out of sync with how browsers were actually using cookies", but you could also say that the browser implementors were less interested in standards and security than they were in competitive advantage.
>  I'm glad to see a new crew able to take this on with less rancor. Perhaps some of the technical issues that blocked progress before had to get resolved first.
> Larry
> --
> -----Original Message-----
> From: [] On Behalf Of =JeffH
> Sent: Thursday, March 03, 2011 2:11 PM
> To: IETF HTTP State WG; Internet Architecture Board;
> Cc: httpstate chair; Adam Barth; Peter Saint-Andre; Bil Corry
> Subject: Re: 'HTTP State Management Mechanism' to Proposed Standard
> Mea culpa :(
> I relied on my obviously faulty memory this morning in my haste rather than
> going back (only 2+ yrs ;) and reviewing mailing list archives, and so didn't
> recall that Bil was instrumental in the creation of this effort.
> Many thanks to Bil for instigating this effort. Here's something he wrote wrt
> the history of this recent edition of the http-state working group..
>   "A bit of history on this effort, it was well known within the IETF
> community that the supposed "official" cookie specification (RFC2965) was
> out-of-sync with how browsers were actually using cookies -- the browser
> vendors never implemented RFC2965 (except Opera).  Anyone wanting to consume or
> send cookie headers had to reverse engineer how the browsers were actually
> doing it as there wasn't (until now) a specification an implementer could use
> for reference.  This lead to a variety of divergence on edge-cases for cookies
> within the implementations.
>   In late 2008, Jim Manico and I connected to create a specification for
> HTTPOnly -- we saw the security issues arising from how the browser vendors
> were implementing HTTPOnly in varying ways[1] due to a lack of a specification
> and formed an ad-hoc working group to tackle the issue[2].
>   When I approached the IETF about forming a charter for an official working
> group, I was told that I was <quote> "wasting my time" because cookies itself
> did not have a proper specification, so it didn't make sense to work on a spec
> for HTTPOnly.  Soon after, we pursued reopening the IETF httpstate Working
> Group to tackle the entire cookie spec, not just HTTPOnly.  Eventually Adam
> Barth would become editor and Jeff Hodges our chair.
>   This cleans up a well-known mess and gives us a good starting point from
> which to improve httpstate and add improved security features.
>   And no, it's not lost on me that HTTPOnly still has considerable divergence
> on behavior.  Perhaps now I can finally form my HTTPOnly working group.
> (Bil Corry)"
> HTH,
> =JeffH