Re: [http-state] http-state charter

Dan Winship <dan.winship@gmail.com> Tue, 04 August 2009 00:13 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 0AC0E3A6DBD for <http-state@core3.amsl.com>; Mon, 3 Aug 2009 17:13:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Level:
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
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 OIx33qAPPYHQ for <http-state@core3.amsl.com>; Mon, 3 Aug 2009 17:13:11 -0700 (PDT)
Received: from mysterion.org (mysterion.org [69.25.196.35]) by core3.amsl.com (Postfix) with ESMTP id 2BF0A28C1FA for <http-state@ietf.org>; Mon, 3 Aug 2009 17:13:11 -0700 (PDT)
Received: from desktop.home.mysterion.org (c-76-97-71-164.hsd1.ga.comcast.net [76.97.71.164]) by mysterion.org (Postfix) with ESMTPA id 6E536802AE; Mon, 3 Aug 2009 20:13:13 -0400 (EDT)
Message-ID: <4A777D12.5000106@gmail.com>
Date: Mon, 03 Aug 2009 20:13:06 -0400
From: Dan Winship <dan.winship@gmail.com>
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1b3pre) Gecko/20090513 Fedora/3.0-2.3.beta2.fc11 Thunderbird/3.0b2
MIME-Version: 1.0
To: Bil Corry <bil@corry.biz>
References: <4A70D2D2.9050900@corry.biz> <4A731FCC.5040102@gmail.com> <4A735DD4.9040007@corry.biz>
In-Reply-To: <4A735DD4.9040007@corry.biz>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Cc: "http-state@ietf.org" <http-state@ietf.org>
Subject: Re: [http-state] http-state charter
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: Tue, 04 Aug 2009 00:13:12 -0000

On 07/31/2009 05:10 PM, Bil Corry wrote:
> Dan Winship wrote on 7/31/2009 11:46 AM: 
>> So I think the goal should be to first produce an Informational RFC,
>> describing real-world cookies, and then either (a) have 2965
>> reclassified as historical, or (b) write a second RFC obsoleting 2965
>> and providing a new profile of Cookie/Set-Cookie usage that is both
>> acceptable to the IETF and compatible with existing usage. (So it would
>> end up being a lot more like 2109 than 2965.)
> 
> Do you think we can skip the Informational RFC and jump straight to
> writing a RFC that obsoletes RFC 2965?

I am not an RFC expert (IANAIANA?) and am just basing this on what I've
absorbed through IETF mailing list osmosis, but there are various things
in the real-world-cookie spec that I imagine would result in it being
rejected as a standards-track RFC. Eg:

    * Cookies are built on top of HTTP, but violate one of RFC 2616's
      MUST-level rules (because Set-Cookie headers can appear more than
      once in a message but can't be merged together)

    * The handling of domains makes wildly unjustified assumptions
      about organization and delegation of authority in DNS. (And in
      fact, every implementation makes *different* assumptions.)

But if you try to fix those things, then you're no longer documenting
how cookies are *actually* implemented.

Hm... maybe we could do it by producing a "cleaned up" cookie spec, with
an appendix explaining the various ways that real-world implementations
deviate from the spec? (I guess RFC 2109 might be a starting point for
the cleaned-up spec... and it's already been accepted as an RFC.)

The question though is whether the "cleaned up" version is actually
going to be useful to anyone, or if everyone will just ignore it like
2109 and 2965. If it's not going to be used, then there's not much
reason to do things that way, as opposed to just documenting the
existing cookie behavior as a non-standards-track document. But I guess
this ties into whatever goals the WG would have *other* than
documenting-existing-cookies.

-- Dan