Re: RFC 20 status change last call: References to appendices

Carsten Bormann <cabo@tzi.org> Fri, 02 January 2015 15:13 UTC

Return-Path: <cabo@tzi.org>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4FB761A87B0 for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 07:13:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.55
X-Spam-Level:
X-Spam-Status: No, score=-1.55 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_DE=0.35] autolearn=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4WL7OCGC7ypc for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 07:13:17 -0800 (PST)
Received: from mailhost.informatik.uni-bremen.de (mailhost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::12]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4B4001A87A8 for <ietf@ietf.org>; Fri, 2 Jan 2015 07:13:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at informatik.uni-bremen.de
Received: from submithost.informatik.uni-bremen.de (submithost.informatik.uni-bremen.de [IPv6:2001:638:708:30c9::b]) by mailhost.informatik.uni-bremen.de (8.14.5/8.14.5) with ESMTP id t02FDBJb000365; Fri, 2 Jan 2015 16:13:11 +0100 (CET)
Received: from [IPv6:2002:5489:25ab::8872:b4c:8003:33b1] (unknown [IPv6:2002:5489:25ab:0:8872:b4c:8003:33b1]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by submithost.informatik.uni-bremen.de (Postfix) with ESMTPSA id 3kDV9L6K3yz7ySP; Fri, 2 Jan 2015 16:13:10 +0100 (CET)
Content-Type: text/plain; charset=utf-8
Mime-Version: 1.0 (Mac OS X Mail 8.1 \(1993\))
Subject: Re: RFC 20 status change last call: References to appendices
From: Carsten Bormann <cabo@tzi.org>
In-Reply-To: <54A69B1E.60903@gmx.de>
Date: Fri, 2 Jan 2015 16:13:09 +0100
X-Mao-Original-Outgoing-Id: 441904388.894445-1216d1fa5b7e2bc2e50c61516ea25f37
Content-Transfer-Encoding: quoted-printable
Message-Id: <631B2422-3C00-46CC-9D10-E3AED644683C@tzi.org>
References: <54A45EA8.2020408@dial.pipex.com> <54A69B1E.60903@gmx.de>
To: Julian Reschke <julian.reschke@gmx.de>
X-Mailer: Apple Mail (2.1993)
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/DzOjvLVqoUCcnXvROEW9GnsO0dI
Cc: IETF Discussion List <ietf@ietf.org>
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Fri, 02 Jan 2015 15:13:19 -0000

On 02 Jan 2015, at 14:20, Julian Reschke <julian.reschke@gmx.de> wrote:
> 
> rfc20bis

The original intention was to have a low-effort procedure to recognize RFC 20 for its standards status.
I continue to believe this is the right thing to do.

I do believe it would be a worthwhile effort to think about the place that ASCII has in Internet protocols in 2015, but if there is a result from that, that would be a quite different document.

The current discussion is to a large extent about the way the original RFC was turned into the online version.
AFAIK, we haven’t had this discussion at all for any of the reconstructed RFCs.
And I’m not sure that the rules for new RFCs fit with the reconstructed ones.
The original RFC has been issued on paper, and that is what shouldn’t change, not necessarily the (always less than perfect) rendition as plaintext.  But there is a cost to giving up the translation of the “RFCs never change” mantra into “RFC files never change”, even for the reconstructed files, and I’m not sure this can of worms needs to be opened.

TL;DR: if the IETF falls into the usual fallacy of perfection [1], it may not be possible to do what we set out to do.

Grüße, Carsten

[1]: Section 2.7, http://www.iab.org/wp-content/IAB-uploads/2011/04/Bormann.pdf