Re: [http-state] consensus call: cookie server conformance

Dan Winship <dan.winship@gmail.com> Sat, 29 January 2011 16:12 UTC

Return-Path: <dan.winship@gmail.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 B70833A6833 for <http-state@core3.amsl.com>; Sat, 29 Jan 2011 08:12:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.717
X-Spam-Level:
X-Spam-Status: No, score=-2.717 tagged_above=-999 required=5 tests=[AWL=-1.040, BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311]
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 47PvZbzAE428 for <http-state@core3.amsl.com>; Sat, 29 Jan 2011 08:12:00 -0800 (PST)
Received: from mysterion.org (li168-117.members.linode.com [173.230.128.117]) by core3.amsl.com (Postfix) with ESMTP id C01E83A6814 for <http-state@ietf.org>; Sat, 29 Jan 2011 08:12:00 -0800 (PST)
Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPSA id 952E734A3D; Sat, 29 Jan 2011 11:15:09 -0500 (EST)
Message-ID: <4D443D0C.2050009@gmail.com>
Date: Sat, 29 Jan 2011 11:15:08 -0500
From: Dan Winship <dan.winship@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) Gecko/20101209 Fedora/3.1.7-0.35.b3pre.fc14 Thunderbird/3.1.7
MIME-Version: 1.0
To: Anne van Kesteren <annevk@opera.com>
References: <4D41FA83.5040302@KingsMountain.com> <4D433C9A.7010203@gmail.com> <op.vp2e7uyj64w2qv@anne-van-kesterens-macbook-pro.local>
In-Reply-To: <op.vp2e7uyj64w2qv@anne-van-kesterens-macbook-pro.local>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: IETF HTTP State WG <http-state@ietf.org>
Subject: Re: [http-state] consensus call: cookie server conformance
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: Sat, 29 Jan 2011 16:12:01 -0000

On 01/29/2011 05:24 AM, Anne van Kesteren wrote:
> On Fri, 28 Jan 2011 23:00:58 +0100, Dan Winship <dan.winship@gmail.com>;
> wrote:
>> -1, because Section 4 says "cookie-value=token", which is annoying
>> (since it prohibits both base64 and URI encoding, both of which are
>> commonly used) and unnecessary for interoperability (both existing and
>> future clients will DTRT with non-token values) and widely violated by
>> real-world servers that would otherwise be considered well-behaved.
>>
>> I suppose I could probably be happy with
>>
>>     cookie-value  = token | base64-string
>>     base64-string = <a base64 string, defined in [RFC4648], Section 4>
>>
>> and then change the later Base 16 reference back to Base 64. This still
>> declares lots of perfectly-interoperable servers "non-compliant", but it
>> at least provides them with a sane way out.
> 
> Why would we not want to their usage conforming too?

Well, really, very few servers are going to be fully conforming right
away, since the majority don't use rfc1123-date for Expires, etc.
(There's no way we can have a sane server grammar and NOT declare at
least 50% of existing servers non-compliant.) The question is how hard
it is for them to become compliant (if they care) and how hard it is for
new servers to start out compliant. (And how ugly we want to let the
"sane" grammar get.)

But then again, why should servers care about becoming compliant?
Compliant clients MUST be able to deal with servers that violate every
single line of the Section 4 grammar, and non-compliant clients are not
guaranteed to deal with Max-Age, so for a server, compliance with the
section 4 grammar is neither necessary nor sufficient to guarantee
interoperability. So what exactly is "compliant server" supposed to
mean, besides "You get a gold star"?

I think "well-behaved" was a good description of Section 4, and we
should just leave it at that, and not even say that servers SHOULD obey it.

(So that's a change to my previous vote. I still think we should open up
the definition of cookie-value a bit, to closer reflect reality, and to
get rid of the silly Base 16 suggestion. But I'm -1 to "MUST" even after
that.)

-- Dan