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

Adam Barth <ietf@adambarth.com> Mon, 15 March 2010 06:04 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 47B7E3A68C6 for <http-state@core3.amsl.com>; Sun, 14 Mar 2010 23:04:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.977
X-Spam-Level:
X-Spam-Status: No, score=-1.977 tagged_above=-999 required=5 tests=[AWL=0.000, 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 IFm8gbDdvRIj for <http-state@core3.amsl.com>; Sun, 14 Mar 2010 23:04:17 -0700 (PDT)
Received: from mail-gw0-f44.google.com (mail-gw0-f44.google.com [74.125.83.44]) by core3.amsl.com (Postfix) with ESMTP id 9F6033A68E3 for <http-state@ietf.org>; Sun, 14 Mar 2010 23:04:05 -0700 (PDT)
Received: by gwj18 with SMTP id 18so1398224gwj.31 for <http-state@ietf.org>; Sun, 14 Mar 2010 23:04:09 -0700 (PDT)
Received: by 10.90.14.13 with SMTP id 13mr312406agn.112.1268633049484; Sun, 14 Mar 2010 23:04:09 -0700 (PDT)
Received: from mail-gx0-f214.google.com (mail-gx0-f214.google.com [209.85.217.214]) by mx.google.com with ESMTPS id 34sm1329726yxf.54.2010.03.14.23.04.07 (version=SSLv3 cipher=RC4-MD5); Sun, 14 Mar 2010 23:04:08 -0700 (PDT)
Received: by gxk6 with SMTP id 6so1806176gxk.14 for <http-state@ietf.org>; Sun, 14 Mar 2010 23:04:07 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.150.184.21 with SMTP id h21mr2863646ybf.260.1268633004514; Sun, 14 Mar 2010 23:03:24 -0700 (PDT)
In-Reply-To: <op.u9kzyfebvqd7e2@killashandra.oslo.osa>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9dpzpdoqrq7tp@acorna> <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com> <op.u9exs1lkvqd7e2@killashandra.oslo.osa> <5c4444771003110942n5b707bedoec7154ebf59cf43e@mail.gmail.com> <op.u9kzyfebvqd7e2@killashandra.oslo.osa>
From: Adam Barth <ietf@adambarth.com>
Date: Sun, 14 Mar 2010 23:03:04 -0700
Message-ID: <5c4444771003142303t220d6616o4e469a38d8147e35@mail.gmail.com>
To: yngve@opera.com
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable
Cc: 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 06:04:18 -0000

On Sun, Mar 14, 2010 at 4:38 PM, Yngve Nysaeter Pettersen
<yngve@opera.com> wrote:
> On Thu, 11 Mar 2010 18:42:51 +0100, Adam Barth <ietf@adambarth.com> wrote:
>> On Thu, Mar 11, 2010 at 9:06 AM, Yngve Nysaeter Pettersen
>> <yngve@opera.com> wrote:
>>>
>>> On Thu, 11 Mar 2010 03:23:03 +0100, Adam Barth <ietf@adambarth.com>
>>> wrote:
>>>>>
>>>>> * 4.1 definition of Max-age is missing. It is used in 5.2.1
>>>>
>>>> This is intentional.  The folks in the working group didn't think we
>>>> should recommend Max-Age to server operators because it's not
>>>> implemented in Internet Explorer.  I'm optimistic that IE will
>>>> implement it, but that's why it's not there.
>>>
>>> I still think it should be there, perhaps with a note that not all
>>> clients
>>> support it (Opera didn't until a couple of years ago), and that servers
>>> should complement it with an Expires attribute.
>>
>> Feel free to convince the working group on this point.  I support
>> describing it in Section 4.  It seems odd to leave out only one of the
>> attributes.
>
> IMO the syntax section of a specification should be complete enough that a
> reader can know "at a glance" what elements the possibilities the
> specification embodies, even if there are agents that are currently not
> using some of the syntax elements. There should be no "surprise" attributes
> that show up later in the document, whose existence cannot be derived from
> being part of some kind of syntax group.
>
> If, as in this case, a particular element is not in use by at least one
> major client (plus older legacy clients), then that should be documented by
> at least a comment to the syntax, and other parts of the document should
> elaborate on that and specify how a server should use the attribute in an
> interoperable fashion.
>
> There may be situations, such as in HTTP, where the exact details for a
> given header is specified in a section (or multiple sections) of its own,
> but even then the header is mentioned in the syntax summary.
>
> While I would prefer the entire Max-age syntax in Section 4, one possible
> way to address the concerns mentioned could be to include a
> "max-age-attribute" element in Section 4, and then have the entire
> definition in the later section. IMO that would also look odd, and it is
> better to have the entire syntax in Section 4.

I think you misunderstand the structure of the document.  Section 4 is
not about the syntax of the protocol.  It's about a subset of the
protocol that servers can use reliably.  I need to make that clearer
in the document.  The syntax of the protocol is defined in Section 5.

Adam