Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG?

Stefanos Harhalakis <v13@priest.com> Thu, 30 August 2007 15:19 UTC

Return-path: <discuss-bounces@apps.ietf.org>
Received: from [127.0.0.1] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQlo8-00033h-Fo; Thu, 30 Aug 2007 11:19:44 -0400
Received: from discuss by megatron.ietf.org with local (Exim 4.43) id 1IQ4V8-0002m9-Od for discuss-confirm+ok@megatron.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400
Received: from [10.91.34.44] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1IQ4V8-0002lb-EU for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400
Received: from mx-out.forthnet.gr ([193.92.150.103]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1IQ4V6-0000KW-Ex for discuss@apps.ietf.org; Tue, 28 Aug 2007 13:05:14 -0400
Received: from mx-av-04.forthnet.gr (mx-av.forthnet.gr [193.92.150.27]) by mx-out-02.forthnet.gr (8.14.0/8.14.0) with ESMTP id l7SH4rhd023009; Tue, 28 Aug 2007 20:04:53 +0300
Received: from MX-IN-03.forthnet.gr (mx-in-03.forthnet.gr [193.92.150.26]) by mx-av-04.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SH4rG3007155; Tue, 28 Aug 2007 20:04:53 +0300
Received: from hell.hell.gr (ppp169-175.adsl.forthnet.gr [62.1.163.175]) by MX-IN-03.forthnet.gr (8.14.1/8.14.1) with ESMTP id l7SH4old011649; Tue, 28 Aug 2007 20:04:51 +0300
From: Stefanos Harhalakis <v13@priest.com>
To: Alexey Melnikov <alexey.melnikov@isode.com>
Subject: Re: HTTPBis BOF followup - should RFC 2965 (cookie) be in scope for the WG?
Date: Tue, 28 Aug 2007 20:04:49 +0300
User-Agent: KMail/1.9.7
References: <46BDE53B.1070404@isode.com> <46D332AD.5070702@isode.com>
In-Reply-To: <46D332AD.5070702@isode.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-7"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200708282004.49749.v13@priest.com>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 0bc60ec82efc80c84b8d02f4b0e4de22
X-Mailman-Approved-At: Thu, 30 Aug 2007 11:19:43 -0400
Cc: Apps Discuss <discuss@apps.ietf.org>, HTTP Working Group <ietf-http-wg@w3.org>
X-BeenThere: discuss@apps.ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: general discussion of application-layer protocols <discuss.apps.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=unsubscribe>
List-Post: <mailto:discuss@apps.ietf.org>
List-Help: <mailto:discuss-request@apps.ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/discuss>, <mailto:discuss-request@apps.ietf.org?subject=subscribe>
Errors-To: discuss-bounces@apps.ietf.org

On Monday 27 August 2007, Alexey Melnikov wrote:
> Alexey Melnikov wrote:
> > Hi folks,
> > Answers to this question during the BOF were not conclusive, so I
> > would like to poll mailing list members on whether revision of RFC
> > 2965 (HTTP State Management Mechanism) should be in scope for the
> > proposed WG.
> >
> > Question: Should RFC 2965 revision be in scope for the WG?
> >
> > Please chose one of the following answers:
> >
> > 1). No
> > 2). Yes
> > 3). Maybe (this includes "yes, but when the WG completes the currently
> > proposed milestones" and "yes, but this should be done in another WG")
> > 4). I have another opinion, which is ....
> >
> > Please send answers to the mailing list, or directly to me *and* Mark
> > Nottingham <mnot@mnot.net>.
> > And of course feel free to ask clarifying questions/correct list of
> > answers.
>
> If you haven't replied to this question, please send your replies by
> September 3rd.

I don't know if I'm supposed to vote, but I'd suggest 1 (No). The rationale 
can be summarized in the question: "Why yes?". 







to 4:
Discuss it in the list first. 

  Then, maybe vote for '3'.

  After reading the minutes (again), I understand that this will only change 
RFC 2695 to 'become' the Netscape doc. So, I don't actually see it as a hi 
priority issue, thinking that a well accepted document already exists 
(Netscape) and there is no confusion. Also, shouldn't this become a new RFC 
that will replace 2695?