Re: [http-state] Welcome to http-state

Dan Winship <> Tue, 13 January 2009 17:12 UTC

Return-Path: <>
Received: from [] (localhost []) by (Postfix) with ESMTP id 6DFDD28C13F; Tue, 13 Jan 2009 09:12:17 -0800 (PST)
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0B6E03A6912 for <>; Tue, 13 Jan 2009 09:12:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.265
X-Spam-Status: No, score=-2.265 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nAWJxCwc1cUK for <>; Tue, 13 Jan 2009 09:12:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 34EA43A6A16 for <>; Tue, 13 Jan 2009 09:12:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTPA id 9E5C48028D for <>; Tue, 13 Jan 2009 12:11:58 -0500 (EST)
Message-ID: <>
Date: Tue, 13 Jan 2009 12:11:30 -0500
From: Dan Winship <>
User-Agent: Thunderbird (X11/20090105)
MIME-Version: 1.0
To: Discuss HTTP State Management Mechanism <>
References: <> <120206B6A348CA498C70E738A2E963514C0CCC@Nexus.cisecurity.lan> <> <120206B6A348CA498C70E738A2E963514C0CD2@Nexus.cisecurity.lan> <> <120206B6A348CA498C70E738A2E963514C0CD5@Nexus.cisecurity.lan> <>
In-Reply-To: <>
Subject: Re: [http-state] Welcome to http-state
X-Mailman-Version: 2.1.9
Precedence: list
Reply-To: Discuss HTTP State Management Mechanism <>
List-Id: Discuss HTTP State Management Mechanism <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit

Adam Barth wrote:
> I'm not an expert on what is or is not in scope for this working
> group

We're not actually a working group yet, so we don't have a charter, so
nothing is specifically in or out of scope yet.

The deliverable that some people want is an Informational RFC explaining
how cookies are actually used *right now* (as opposed to "how we wish
they worked"), with notes on areas of incompatibility, and discussion of
known security problems.

If we want to actually make cookies better, then we need to be careful
to not just create yet-another-improved-cookie-spec-that-everyone-
ignores (as Daniel Stenberg already noted). So there are two kinds of
things we can do:

    * Find ways to make cookies better that don't require web developers
      to change their behavior. (Eg, draft-pettersen-dns-cookie-validate
      and draft-pettersen-subtld-structure.)

    * Find ways to make cookies better that we can somehow force/trick/
      bribe web developers into using.

One way to make the new spec compelling might be to add some feature
that would be needed by some other useful spec like
Cookie-based-HTTP-auth (draft-broyer-http-cookie-auth, currently being
discussed on the ietf-http-auth list). Or to have new cookies integrate
with HTML5 in some exciting way that old cookies wouldn't be able to.

Likewise, even though it would be cleaner to scrap Set-Cookie and
replace it with a new header a la Set-Cookie2, developers are going to
want backward-compatibility, and don't want to have to set each cookie
twice (for bandwidth reasons), so the best solution for new features may
be to add new attributes to Set-Cookie (keeping in mind that old
implementations would still see the cookies but would ignore the new

-- Dan
http-state mailing list