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

Bjoern Hoehrmann <> Sat, 29 January 2011 20:16 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 5FD3E3A686A for <>; Sat, 29 Jan 2011 12:16:04 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.234
X-Spam-Status: No, score=-3.234 tagged_above=-999 required=5 tests=[AWL=-0.635, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id oxIvWmakIEZL for <>; Sat, 29 Jan 2011 12:16:03 -0800 (PST)
Received: from ( []) by (Postfix) with SMTP id DD7523A681C for <>; Sat, 29 Jan 2011 12:16:02 -0800 (PST)
Received: (qmail invoked by alias); 29 Jan 2011 20:19:10 -0000
Received: from (EHLO hive) [] by (mp016) with SMTP; 29 Jan 2011 21:19:10 +0100
X-Authenticated: #723575
X-Provags-ID: V01U2FsdGVkX1+HNx1CtUmHS4J9PNxFB+H/RnWp8atRo8PQVkKF5x V/unsx11pdfZja
From: Bjoern Hoehrmann <>
To: =JeffH <>
Date: Sat, 29 Jan 2011 21:19:03 +0100
Message-ID: <>
References: <>
In-Reply-To: <>
X-Mailer: Forte Agent 3.3/32.846
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Y-GMX-Trusted: 0
Cc: IETF HTTP State WG <>
Subject: Re: [http-state] consensus call: cookie server conformance
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 29 Jan 2011 20:16:04 -0000

* =JeffH wrote:
>Absent explicitly expressed opposing views here on the http-state@ mailing 
>list, I'm going to interpret the WG's consensus to be in favor of the 
>modification as proposed by PeterSA...

I think the Working Group should recharter, or, alternatively, do what
the charter says. Apart from producing a proper test suite and a proper
description of deviations from the main specification, that would mean
replacing, say, the date parsing algorithm that's been made up on the
spot, and not doing what is proposed here, namely describing the proto-
col in a manner that is inconsistent with the vast majority of servers.

At the very least I would expect the main specification to say that the
protocol it describes is how some people wish it would work, instead of
incorrectly claiming it is an actual description of how it's "actually
used on the Internet". I don't mind requirements that are unlikely to
ever propagate into practise, but I do mind being dishonest about them.
Björn Höhrmann · ·
Am Badedeich 7 · Telefon: +49(0)160/4415681 ·
25899 Dagebüll · PGP Pub. KeyID: 0xA4357E78 ·