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

David Morris <dwm@xpasc.com> Mon, 15 March 2010 17:19 UTC

Return-Path: <dwm@xpasc.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 E7F253A6C17 for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 10:19:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.68
X-Spam-Level:
X-Spam-Status: No, score=-2.68 tagged_above=-999 required=5 tests=[AWL=-0.081, BAYES_00=-2.599]
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 sF5l3ORluAvZ for <http-state@core3.amsl.com>; Mon, 15 Mar 2010 10:19:34 -0700 (PDT)
Received: from mail.xpasc.com (mail.xpasc.com [68.164.244.189]) by core3.amsl.com (Postfix) with ESMTP id F19AF3A68A0 for <http-state@ietf.org>; Mon, 15 Mar 2010 10:16:56 -0700 (PDT)
Received: from bslepgate.xpasc.com (localhost.localdomain [127.0.0.1]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 7AD791018DF for <http-state@ietf.org>; Mon, 15 Mar 2010 10:17:05 -0700 (PDT)
X-Propel-Return-Path: <dwm@xpasc.com>
Received: from mail.xpasc.com ([10.1.2.88]) by [127.0.0.1] ([127.0.0.1]) (port 7027) (Abaca EPG outproxy filter 3.1.1.9347 $Rev: 9262 $) id iz6Ura3fhh50; Mon, 15 Mar 2010 10:17:05 -0700
Received: from xpasc.com (egate.xpasc.com [10.1.2.49]) by bslepgate.xpasc.com (Postfix-out) with ESMTP id 517891018DE for <http-state@ietf.org>; Mon, 15 Mar 2010 10:17:05 -0700 (PDT)
Received: from egate.xpasc.com (egate.xpasc.com [10.1.2.49]) by xpasc.com (8.13.8/8.13.8) with ESMTP id o2FHH2dA000900 for <http-state@ietf.org>; Mon, 15 Mar 2010 10:17:04 -0700
Date: Mon, 15 Mar 2010 10:17:02 -0700
From: David Morris <dwm@xpasc.com>
To: http-state <http-state@ietf.org>
In-Reply-To: <5c4444771003150921x6c8b4061x4fc53335845a0d4d@mail.gmail.com>
Message-ID: <Pine.LNX.4.64.1003151010180.4222@egate.xpasc.com>
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>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset="US-ASCII"
X-Propel-ID: iz6Ura3fhh50
Subject: Re: [http-state] draft-ietf-httpstate-cookie-05 posted
X-BeenThere: http-state@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: http-state <http-state@ietf.org>
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 17:19:39 -0000

On Mon, 15 Mar 2010, Adam Barth wrote:

> On Mon, Mar 15, 2010 at 9:14 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
>
> > It has been reserved, should be reserved, and seems to be only used *very*
> > rarely...
> 
> 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.

I interpret 'reserved' as an advisory term ... it doesn't place any new
requirement on User Agents but does warn the world that use is not 
considered appropriate. Since it is apparently know who some of the
design firms are, it might be a good approach to informally remind
them of the reserved status. 

Since the actual use is server controlled, it doesn't seem unreasonable
to expect a change could be implemented over the many months between when
this work is published as an RFC and when the first browser update
might decide to enforce the reservation... perhaps as an invalid cookie
warning popup?