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

Julian Reschke <julian.reschke@gmx.de> Fri, 02 January 2015 15:27 UTC

Return-Path: <julian.reschke@gmx.de>
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 47A131A87C7 for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 07:27:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham
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 cRTvl-wiMUtk for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 07:27:52 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEE4E1A879E for <ietf@ietf.org>; Fri, 2 Jan 2015 07:27:51 -0800 (PST)
Received: from [192.168.1.194] ([217.91.35.233]) by mail.gmx.com (mrgmx103) with ESMTPSA (Nemesis) id 0LjJCt-1XYYP41Qbv-00dXYR; Fri, 02 Jan 2015 16:27:49 +0100
Message-ID: <54A6B8EE.6090803@gmx.de>
Date: Fri, 02 Jan 2015 16:27:42 +0100
From: Julian Reschke <julian.reschke@gmx.de>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
To: Carsten Bormann <cabo@tzi.org>
Subject: Re: RFC 20 status change last call: References to appendices
References: <54A45EA8.2020408@dial.pipex.com> <54A69B1E.60903@gmx.de> <631B2422-3C00-46CC-9D10-E3AED644683C@tzi.org>
In-Reply-To: <631B2422-3C00-46CC-9D10-E3AED644683C@tzi.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Provags-ID: V03:K0:RNzi1Sc2MnUL7w0+nibiKeITxHxn2XvSY9rvC7ko1Ma05+ytuiL Kq+UPgDKqCX1Q4jPHtcMQTIpV1cqSgWjXakL6rcFBBlc/ot/LapM4ftdujaCIEaacNWGPE9 /edAGfLnRwCXCRCFR+Vs4hyzZKjLdPplQAH+m/b5VuDPGI15rktSWzhqpUg7Ak/Gcxz1WKZ ziAtIFy27UrnX+HhYrJZg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/hptoIKGSVeO7JD4kmePTSgwE_KQ
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:27:53 -0000

On 2015-01-02 16:13, Carsten Bormann wrote:
> 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.
> ...

Agreed.

So if this exercise is supposed to make sense, we'll first have to find 
out whether the rfc 20 text file we're looking at actually is a useful 
conversion of the original RFC 20. If it's not, there's no point in 
having a discussion about re-classification until we all can read the 
same document.

Best regards, Julian