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

"Yngve Nysaeter Pettersen" <yngve@opera.com> Sun, 14 March 2010 23:38 UTC

Return-Path: <yngve@opera.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 398A83A6905 for <http-state@core3.amsl.com>; Sun, 14 Mar 2010 16:38:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.206
X-Spam-Level:
X-Spam-Status: No, score=-5.206 tagged_above=-999 required=5 tests=[AWL=-1.207, BAYES_50=0.001, RCVD_IN_DNSWL_MED=-4]
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 dsU-U10ww852 for <http-state@core3.amsl.com>; Sun, 14 Mar 2010 16:38:02 -0700 (PDT)
Received: from smtp.opera.com (smtp.opera.com [213.236.208.81]) by core3.amsl.com (Postfix) with ESMTP id 9EA4F3A691B for <http-state@ietf.org>; Sun, 14 Mar 2010 16:37:53 -0700 (PDT)
Received: from killashandra.oslo.osa (pat-tdc.opera.com [213.236.208.22]) by smtp.opera.com (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id o2ENbn4k014014 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sun, 14 Mar 2010 23:37:57 GMT
Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes
To: "Adam Barth" <ietf@adambarth.com>
References: <5c4444771003071050r3475798co95cc192d1f2e8190@mail.gmail.com> <op.u9dpzpdoqrq7tp@acorna> <5c4444771003101823u25842652o33b49b2be81f4cfc@mail.gmail.com> <op.u9exs1lkvqd7e2@killashandra.oslo.osa> <5c4444771003110942n5b707bedoec7154ebf59cf43e@mail.gmail.com>
Date: Mon, 15 Mar 2010 00:38:29 +0100
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
From: "Yngve Nysaeter Pettersen" <yngve@opera.com>
Organization: Opera Software
Message-ID: <op.u9kzyfebvqd7e2@killashandra.oslo.osa>
In-Reply-To: <5c4444771003110942n5b707bedoec7154ebf59cf43e@mail.gmail.com>
User-Agent: Opera Mail/10.50 (Win32)
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
Reply-To: yngve@opera.com
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, 14 Mar 2010 23:38:04 -0000

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.


-- 
Sincerely,
Yngve N. Pettersen
********************************************************************
Senior Developer		     Email: yngve@opera.com
Opera Software ASA                   http://www.opera.com/
Phone:  +47 24 16 42 60              Fax:    +47 24 16 40 01
********************************************************************