IETF Logo Mail Archive

Re: [http-state] http-state charter

Mark Nottingham <mnot@mnot.net> Wed, 05 August 2009 16:28 UTC

Return-Path: <mnot@mnot.net>
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 3CF653A71A5 for <http-state@core3.amsl.com>; Wed, 5 Aug 2009 09:28:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.599
X-Spam-Level:
X-Spam-Status: No, score=-6.599 tagged_above=-999 required=5 tests=[AWL=-4.000, BAYES_00=-2.599]
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 5fG4oSpNAzkD for <http-state@core3.amsl.com>; Wed, 5 Aug 2009 09:28:34 -0700 (PDT)
Received: from mxout-08.mxes.net (mxout-08.mxes.net [216.86.168.183]) by core3.amsl.com (Postfix) with ESMTP id 1786C3A718B for <http-state@ietf.org>; Wed, 5 Aug 2009 09:28:34 -0700 (PDT)
Received: from [127.0.0.1] (unknown [216.145.54.15]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by smtp.mxes.net (Postfix) with ESMTPSA id 631B8509DC; Wed, 5 Aug 2009 12:28:30 -0400 (EDT)
Message-Id: <F8422F15-2E91-4EFC-B44D-CDD8C89E59C9@mnot.net>
From: Mark Nottingham <mnot@mnot.net>
To: Bil Corry <bil@corry.biz>
In-Reply-To: <4A78EF0E.602@corry.biz>
Content-Type: text/plain; charset="US-ASCII"; format="flowed"; delsp="yes"
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v935.3)
Date: Wed, 05 Aug 2009 09:28:29 -0700
References: <4A70D2D2.9050900@corry.biz> <4A731FCC.5040102@gmail.com> <4A735DD4.9040007@corry.biz> <4A777D12.5000106@gmail.com> <ab2c53a20908041341x2cb954b7h856ccc43b3fb3313@mail.gmail.com> <FD75C039-3A9E-4477-ACC0-249A270615CC@mnot.net> <4A78EF0E.602@corry.biz>
X-Mailer: Apple Mail (2.935.3)
Cc: 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: Wed, 05 Aug 2009 16:28:37 -0000

I think it's agreed that we need to document current behaviour. How  
and where that happens, as well as its relationship to existing specs  
is still something that needs to be discussed more widely, I think.

Cheers,


On 04/08/2009, at 7:31 PM, Bil Corry wrote:

> Mark Nottingham wrote on 8/4/2009 8:26 PM:
>> I would encourage people on this list to discuss how to make that
>> happen, and not to try to second-guess the IETF process, what will  
>> and
>> will not be acceptable to the IESG, etc; we'll get there soon enough.
>
> So is it agreed then that this WG will work to produce a RFC that  
> specifies Cookies as-they-exist-today?
>
> Our charter currently reads (in part):
>
> "The working group will create a new RFC that obsoletes RFC 2965 and
> specifies Cookies as they are used in existing implementations and
> deployments."
>
>
> Does that work?
>
>
> - Bil
>
>


--
Mark Nottingham     http://www.mnot.net/

v2.23.0 | Report a Bug | By Email