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

Larry Masinter <masinter@adobe.com> Sun, 06 March 2011 00:45 UTC

Return-Path: <masinter@adobe.com>
X-Original-To: http-state@core3.amsl.com
Delivered-To: http-state@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 021423A6A43 for <http-state@core3.amsl.com>; Sat, 5 Mar 2011 16:45:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -105.781
X-Spam-Level:
X-Spam-Status: No, score=-105.781 tagged_above=-999 required=5 tests=[AWL=0.818, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id mesMOziKpqtP for <http-state@core3.amsl.com>; Sat, 5 Mar 2011 16:45:21 -0800 (PST)
Received: from exprod6og111.obsmtp.com (exprod6og111.obsmtp.com [64.18.1.27]) by core3.amsl.com (Postfix) with ESMTP id B9BF43A6A16 for <http-state@ietf.org>; Sat, 5 Mar 2011 16:44:42 -0800 (PST)
Received: from source ([192.150.11.134]) by exprod6ob111.postini.com ([64.18.5.12]) with SMTP ID DSNKTXLZP+PLRCUN8jaT1X/uFvV/w4MPaWtR@postini.com; Sat, 05 Mar 2011 16:46:33 PST
Received: from inner-relay-4.eur.adobe.com (inner-relay-4.adobe.com [193.104.215.14]) by outbound-smtp-1.corp.adobe.com (8.12.10/8.12.10) with ESMTP id p260j5ES015926; Sat, 5 Mar 2011 16:45:05 -0800 (PST)
Received: from nacas03.corp.adobe.com (nacas03.corp.adobe.com [10.8.189.121]) by inner-relay-4.eur.adobe.com (8.12.10/8.12.9) with ESMTP id p260jh1R003688; Sat, 5 Mar 2011 16:45:44 -0800 (PST)
Received: from nambxv01a.corp.adobe.com ([10.8.189.95]) by nacas03.corp.adobe.com ([10.8.189.121]) with mapi; Sat, 5 Mar 2011 16:45:43 -0800
From: Larry Masinter <masinter@adobe.com>
To: =JeffH <Jeff.Hodges@KingsMountain.com>, IETF HTTP State WG <http-state@ietf.org>, Internet Architecture Board <iab@iab.org>, "www-tag@w3.org" <www-tag@w3.org>
Date: Sat, 05 Mar 2011 16:45:41 -0800
Thread-Topic: 'HTTP State Management Mechanism' to Proposed Standard
Thread-Index: AcvZ8SxB4+yQs1SAR++crlw11BKSPQBpcrrg
Message-ID: <C68CB012D9182D408CED7B884F441D4D05A032FAFE@nambxv01a.corp.adobe.com>
References: <4D701209.9090008@KingsMountain.com>
In-Reply-To: <4D701209.9090008@KingsMountain.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Approved-At: Sat, 05 Mar 2011 16:53:04 -0800
Cc: httpstate chair <httpstate-chairs@tools.ietf.org>
Subject: Re: [http-state] 'HTTP State Management Mechanism' to Proposed Standard
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <http-state.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/http-state>
List-Post: <mailto:http-state@ietf.org>
List-Help: <mailto:http-state-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/http-state>, <mailto:http-state-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 06 Mar 2011 00:45:23 -0000

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
--
http://larry.masinter.net


-----Original Message-----
From: www-tag-request@w3.org [mailto:www-tag-request@w3.org] On Behalf Of =JeffH
Sent: Thursday, March 03, 2011 2:11 PM
To: IETF HTTP State WG; Internet Architecture Board; www-tag@w3.org
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