Re: [http-state] Updated draft

Adam Barth <ietf@adambarth.com> Mon, 17 August 2009 16:08 UTC

Return-Path: <adam@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 923D028C2AA for <http-state@core3.amsl.com>; Mon, 17 Aug 2009 09:08:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.833
X-Spam-Level:
X-Spam-Status: No, score=-1.833 tagged_above=-999 required=5 tests=[AWL=0.144, 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 gYS2x6Dvh12i for <http-state@core3.amsl.com>; Mon, 17 Aug 2009 09:08:36 -0700 (PDT)
Received: from mail-vw0-f196.google.com (mail-vw0-f196.google.com [209.85.212.196]) by core3.amsl.com (Postfix) with ESMTP id C968F28C2A4 for <http-state@ietf.org>; Mon, 17 Aug 2009 09:08:35 -0700 (PDT)
Received: by vws34 with SMTP id 34so2676588vws.31 for <http-state@ietf.org>; Mon, 17 Aug 2009 09:08:32 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.220.12.203 with SMTP id y11mr4886646vcy.82.1250525312105; Mon, 17 Aug 2009 09:08:32 -0700 (PDT)
In-Reply-To: <7789133a0908170853r5a81b84cu1308049256f51d2c@mail.gmail.com>
References: <7789133a0908151008p35ff30e6w2761368fe70d41a6@mail.gmail.com> <7789133a0908151642w47c1dbf1x48268e657b0d71cc@mail.gmail.com> <alpine.DEB.2.00.0908161440520.25988@yvahk2.pbagnpgbe.fr> <7789133a0908161032l2265ce5fg966c434f1b05aa64@mail.gmail.com> <alpine.DEB.2.00.0908161952060.13789@yvahk2.pbagnpgbe.fr> <7789133a0908161131s5741d457q812b5e4213452054@mail.gmail.com> <alpine.DEB.2.00.0908162035140.13789@yvahk2.pbagnpgbe.fr> <4A889417.9020709@gmail.com> <alpine.DEB.2.00.0908170929100.22132@yvahk2.pbagnpgbe.fr> <7789133a0908170853r5a81b84cu1308049256f51d2c@mail.gmail.com>
From: Adam Barth <ietf@adambarth.com>
Date: Mon, 17 Aug 2009 09:08:12 -0700
Message-ID: <7789133a0908170908r4e3e8d30v7187bbf67f76b95c@mail.gmail.com>
To: Daniel Stenberg <daniel@haxx.se>
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: http-state <http-state@ietf.org>
Subject: Re: [http-state] Updated draft
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, 17 Aug 2009 16:08:36 -0000

On Mon, Aug 17, 2009 at 8:53 AM, Adam Barth<ietf@adambarth.com> wrote:
> There's a clear cost to not specifying the sort order: new
> implementations that follow the spec will behave differently than all
> the major browsers.  However, you haven't articulated a reason why we
> ought not to specify the sort order.

Put another way, if you were writing a new cookie implementation
today, why would you want to use any other sort order?  In the end,
you have to pick an ordering.  You might as well pick the one that's
used by 99% of the market.  Instead of forcing new implementations to
reverse engineer this information, we should just say.

Adam