Re: RFC 20 status change last call: References to appendices
John C Klensin <john-ietf@jck.com> Fri, 02 January 2015 16:05 UTC
Return-Path: <john-ietf@jck.com>
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 B2B311A1B7D for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 08:05:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.101
X-Spam-Level: *
X-Spam-Status: No, score=1.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FH_HOST_EQ_D_D_D_D=0.765, HELO_MISMATCH_COM=0.553, HOST_EQ_STATICB=1.372, HOST_MISMATCH_NET=0.311] 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 wJQF18xiMEZz for <ietf@ietfa.amsl.com>; Fri, 2 Jan 2015 08:05:07 -0800 (PST)
Received: from bsa3.jck.com (static-65-175-133-137.cpe.metrocast.net [65.175.133.137]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 28CF51A1B5A for <ietf@ietf.org>; Fri, 2 Jan 2015 08:05:05 -0800 (PST)
Received: from hp5.int.jck.com ([198.252.137.153] helo=P5) by bsa3.jck.com with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <john-ietf@jck.com>) id 1Y74ii-0001IW-UK; Fri, 02 Jan 2015 11:05:00 -0500
Date: Fri, 02 Jan 2015 11:04:55 -0500
From: John C Klensin <john-ietf@jck.com>
To: Carsten Bormann <cabo@tzi.org>, Julian Reschke <julian.reschke@gmx.de>
Subject: Re: RFC 20 status change last call: References to appendices
Message-ID: <EA211F2E8783F1180D89E83D@P5>
In-Reply-To: <631B2422-3C00-46CC-9D10-E3AED644683C@tzi.org>
References: <54A45EA8.2020408@dial.pipex.com> <54A69B1E.60903@gmx.de> <631B2422-3C00-46CC-9D10-E3AED644683C@tzi.org>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/r7n9duacBbBpM8pve3zx-e6QsBM
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 16:05:13 -0000
+1. I would add that, under our current rules, it would be almost impossible for an RFC20bis to satisfy the needs of most of the documents that reference RFC20: it is hard to find copies of the relevant version of ASCII, both IETF and ANSI have gotten a lot more careful about copyrights, and so on. If someone can find a copy of the original (paper, with appendices) version of RFC 20 and get it online in page image form, that would be great. I'm trying to find time to look for mine. And, like Carsten, I think a new document on the role of ASCII in the Internet going forward would be great-- but that is more likely RFC 2277bis than RFC20bis. Let's just recognize that making rules retroactive to a 40+ year old spec is not likely to be fruitful. Even if one were to examine RFC 854 -- 13 or 14 years later than RFC 20 and classified as a full standard when that sweep was done -- there are no explicit references, no author addresses (not that they would do much good any more), no "IANA Considerations" describing the options registry, no IPR boilerplate, no Security Considerations even though the protocol often transmits passwords in the clear over unsecured connections, etc. Should we deprecate it or mount an effort to replace it? Trying to apply today's norms may or may not advance the quest for perfection (fallacy included), but it would certainly lead to madness. john --On Friday, 02 January, 2015 16:13 +0100 Carsten Bormann <cabo@tzi.org> 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. > > 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 >
- Re: RFC 20 status change last call: References to… John Levine
- RFC 20 status change last call: References to app… Elwyn Davies
- Re: RFC 20 status change last call: References to… Julian Reschke
- Re: RFC 20 status change last call: References to… Carsten Bormann
- Re: RFC 20 status change last call: References to… Julian Reschke
- Re: RFC 20 status change last call: References to… John C Klensin
- Re: RFC 20 status change last call: References to… ned+ietf
- Re: RFC 20 status change last call: References to… Nico Williams
- Re: RFC 20 status change last call: References to… Brian E Carpenter
- Re: RFC 20 status change last call: References to… Julian Reschke
- Re: RFC 20 status change last call: References to… John Levine
- Re: RFC 20 status change last call: References to… Nico Williams
- Re: RFC 20 status change last call: References to… Julian Reschke
- Re: RFC 20 status change last call: References to… Nico Williams
- Re: RFC 20 status change last call: References to… Harald Alvestrand
- Re: RFC 20 status change last call: References to… Måns Nilsson
- Re: RFC 20 status change last call: References to… John Levine
- Re: RFC 20 status change last call: References to… John Levine
- Re: RFC 20 status change last call: References to… David Farmer
- "nothing of importance" (was: Re: RFC 20 status c… Stephen Farrell
- Re: RFC 20 status change last call: References to… Tony Hansen