Re: [http-state] draft-ietf-httpstate-cookie-05 posted

Adam Barth <ietf@adambarth.com> Mon, 15 March 2010 16:57 UTC

Return-Path: <ietf@adambarth.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 477A73A69DF for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 09:57:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.943
X-Spam-Level:
X-Spam-Status: No, score=-1.943 tagged_above=-999 required=5 tests=[AWL=0.034, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622]
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 qJhJ5g7HL0yX for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 09:57:07 -0700 (PDT)
Received: from mail-pz0-f178.google.com (mail-pz0-f178.google.com [209.85.222.178]) by core3.amsl.com (Postfix) with ESMTP id 206323A68A5 for <http-state@ietf.org>; Mon, 15 Mar 2010 09:56:55 -0700 (PDT)
Received: by pzk8 with SMTP id 8so2787935pzk.29 for <http-state@ietf.org>; Mon, 15 Mar 2010 09:56:59 -0700 (PDT)
Received: by 10.143.26.4 with SMTP id d4mr1911993wfj.232.1268672219260; Mon, 15 Mar 2010 09:56:59 -0700 (PDT)
Received: from mail-iw0-f186.google.com (mail-iw0-f186.google.com [209.85.223.186]) by mx.google.com with ESMTPS id 23sm4388751iwn.10.2010.03.15.09.56.58 (version=SSLv3 cipher=RC4-MD5); Mon, 15 Mar 2010 09:56:59 -0700 (PDT)
Received: by iwn16 with SMTP id 16so29908iwn.31 for <http-state@ietf.org>; Mon, 15 Mar 2010 09:56:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.231.190.204 with SMTP id dj12mr429119ibb.9.1268672217286; Mon, 15 Mar 2010 09:56:57 -0700 (PDT)
In-Reply-To: <4B9E60C7.2090006@gmx.de>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9k0zvitqrq7tp@acorna.oslo.opera.com> <alpine.DEB.2.00.1003150915130.17195@tvnag.unkk.fr> <op.u9lshja5qrq7tp@acorna.oslo.opera.com> <5c4444771003150908u252a1813s37f88f45f1aa5a95@mail.gmail.com> <4B9E5CF6.50507@gmx.de> <5c4444771003150921x6c8b4061x4fc53335845a0d4d@mail.gmail.com> <5c4444771003150923u1b965a66l24ab217036923ec0@mail.gmail.com> <4B9E60C7.2090006@gmx.de>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 15 Mar 2010 09:56:36 -0700
Message-ID: <5c4444771003150956x2fb2b302h7a531fadd24876fa@mail.gmail.com>
To: Julian Reschke <julian.reschke@gmx.de>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: Daniel Stenberg <daniel@haxx.se>, http-state <http-state@ietf.org>
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
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: Mon, 15 Mar 2010 16:57:08 -0000

On Mon, Mar 15, 2010 at 9:31 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 15.03.2010 17:23, Adam Barth wrote:
>>> We're only supposed to require user agents to do things that are
>>> already widely implemented.  I'll happily add this requirement if user
>>> agents widely implement it, but that's not the case currently.
>>> There's a bunch of stuff in RFC 2109 that's been "reserved" and
>>> "should be reserved" but the reality today is that it isn't reserved.
>>
>> Another perspective is that there's no big rush to add this
>> requirement.  It's probably not going to make user agents change their
>> behavior appreciably faster.  We might as well wait on moving the
>> mountain to phase 2.
>> ...
>
> Don't require user agents to do anything specific. Just state that is has
> been reserved, continues to be reserved, and that servers must not use it.

I agree that we should add a server requirement not to use cookie
names that begin with $.  I think it's more consistent with our
previous decisions to place the requirement at the SHOULD NOT level.
For example, currently Section 4 (which contains the server
requirements) doesn't have any MUST-level requirements.  If we're
going to add MUST-level requirements, then we should ban some of the
more ridiculous parts of the protocol before we ban use of $.

Adam