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

Tony Hansen <tony@att.com> Mon, 05 January 2015 06:23 UTC

Return-Path: <tony@att.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 78DEE1A1BEA for <ietf@ietfa.amsl.com>; Sun, 4 Jan 2015 22:23:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.889
X-Spam-Level:
X-Spam-Status: No, score=-0.889 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MISSING_HEADERS=1.021, RCVD_IN_DNSWL_NONE=-0.0001, T_RP_MATCHES_RCVD=-0.01] 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 03izWRNosi0O for <ietf@ietfa.amsl.com>; Sun, 4 Jan 2015 22:23:26 -0800 (PST)
Received: from egssmtp02.att.com (egssmtp02.att.com [144.160.128.166]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DB0B31A1BCF for <ietf@ietf.org>; Sun, 4 Jan 2015 22:23:26 -0800 (PST)
Received: from dns.maillennium.att.com (maillennium.att.com [135.25.114.99]) by egssmtp02.att.com ( EGS R6 8.14.5 TLS/8.14.5) with ESMTP id t056NOl4002837 for <ietf@ietf.org>; Sun, 4 Jan 2015 22:23:24 -0800
Received: from vpn-135-70-103-55.vpn.swst.att.com ([135.70.103.55]) by maillennium.att.com (mailgw1) with ESMTP id <20150105062324gw100r93vqe>; Mon, 5 Jan 2015 06:23:24 +0000
X-Originating-IP: [135.70.103.55]
Message-ID: <54AA2DDB.7020300@att.com>
Date: Mon, 05 Jan 2015 01:23:23 -0500
From: Tony Hansen <tony@att.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.3.0
MIME-Version: 1.0
CC: IETF Discussion List <ietf@ietf.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> <EA211F2E8783F1180D89E83D@P5>
In-Reply-To: <EA211F2E8783F1180D89E83D@P5>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/43tfRRh6J-_fYAQIfhYqtTK7qQM
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: Mon, 05 Jan 2015 06:23:28 -0000

As an FYI, all of the text versions were transcribed off of either PDF, 
TIFF or PNG scan images that were provided to those doing the 
transcriptions. These scans were made from paper copies found in various 
cabinets. It's entirely conceivable that the paper copy being used for 
RFC 20 happened to have lost its appendix pages before being scanned. Or 
it may not have had any appendices to begin with. Either scenario is 
possible.

Not that this changes any of the rest of this thread. I'm happy with the 
resolution of having an erratum.

     Tony Hansen

On 1/2/15 11:04 AM, John C Klensin wrote:
> +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
>>
>
>
>