LC changes was Last Call Summaryondraft-yevstifeyev-http-headers-not-recognized

"t.petch" <daedulus@btconnect.com> Sat, 08 January 2011 12:05 UTC

Return-Path: <daedulus@btconnect.com>
X-Original-To: ietf@core3.amsl.com
Delivered-To: ietf@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 0B5F93A69CA; Sat, 8 Jan 2011 04:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.999
X-Spam-Level:
X-Spam-Status: No, score=-2.999 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, J_CHICKENPOX_42=0.6, RCVD_IN_DNSWL_LOW=-1]
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 EtJyEJO-p0fm; Sat, 8 Jan 2011 04:05:09 -0800 (PST)
Received: from mail.btconnect.com (c2beaomr10.btconnect.com [213.123.26.188]) by core3.amsl.com (Postfix) with ESMTP id 191813A69C3; Sat, 8 Jan 2011 04:05:07 -0800 (PST)
Received: from host81-152-224-74.range81-152.btcentralplus.com (HELO pc6) ([81.152.224.74]) by c2beaomr10.btconnect.com with SMTP id BGD22905; Sat, 08 Jan 2011 12:07:13 +0000 (GMT)
Message-ID: <002301cbaf23$c0907580$4001a8c0@gateway.2wire.net>
From: "t.petch" <daedulus@btconnect.com>
To: Julian Reschke <julian.reschke@gmx.de>
References: <4D280272.6090402@gmail.com> <4D28218A.2020406@gmx.de><4D283A42.3080303@gmail.com> <4D2847E1.9090004@gmx.de>
Subject: LC changes was Last Call Summaryondraft-yevstifeyev-http-headers-not-recognized
Date: Sat, 08 Jan 2011 12:03:53 +0100
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2800.1106
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1106
X-Mirapoint-IP-Reputation: reputation=Neutral-1, source=Queried, refid=tid=0001.0A0B0301.4D285371.00C1, actions=tag
X-Junkmail-Status: score=10/50, host=c2beaomr10.btconnect.com
X-Junkmail-Signature-Raw: score=unknown, refid=str=0001.0A0B0209.4D285372.00A2, ss=1, fgs=0, ip=0.0.0.0, so=2010-07-22 22:03:31, dmn=2009-09-10 00:05:08, mode=single engine
X-Junkmail-IWF: false
Cc: iesg@ietf.org, IETF Discussion <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 08 Jan 2011 12:05:10 -0000

----- Original Message -----
From: "Julian Reschke" <julian.reschke@gmx.de>
To: "Mykyta Yevstifeyev" <evnikita2@gmail.com>
Cc: <iesg@ietf.org>; <ietf-message-headers@ietf.org>; "IETF Discussion"
<ietf@ietf.org>; "httpbis Group" <ietf-http-wg@w3.org>
Sent: Saturday, January 08, 2011 12:17 PM
 On 08.01.2011 11:19, Mykyta Yevstifeyev wrote:
> >> If a draft changes three times during LC, there may be a problem. I
> >> encourage you to go back to the drawing board, and think hard(er about
> >> the feedback you got, in particular
> >> <http://lists.w3.org/Archives/Public/ietf-http-wg/2010OctDec/0645.html>.
> > Why do you think that the draft shouldn't be changed during LC?
>
> Because people assume stability during LC, and are unlikely to review
> the spec multiple times during the same LC.
>
> Of course that does not mean that you can't start addressing issues
> during LC. Just do so in a way that it doesn't change what's being
> last-called. For instance, by publishing the current edits on a private
> web page.

That's a relief; I agree absolutely with you, but am very aware that
the last statement on this, from Jari Arkko in August on this list,
explained why he encouraged 'his' editors to keep producing
new versions while the Last Call was in progress, an action that
switches me off completely

Tom Petch

>
> If you have non-editorial changes, the AD will have to decide whether
> they require a new LC.
>
> > Moreover, I had some reasons for doing that. firstly, version -09 added
> > the section that was not present in -08 and if I added it now, there
> > would not be a possibility to discuss it. Version -10 presented the most
>
> There was no stability *because* of these updates.
>
> > stable one to reflect all the comments I received during the LC. And -11
> > was prepared as final for IESG review.
>
> My recommendation to the IESG is to wait for a stable spec, and then
> restart the LC.
>

<snip/>

> Best regards, Julian
>
>