Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)

<> Sat, 06 December 2014 22:49 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id D64351A1B27 for <>; Sat, 6 Dec 2014 14:49:23 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id A8X1TADaA1Xy for <>; Sat, 6 Dec 2014 14:49:21 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1CB801A1AD8 for <>; Sat, 6 Dec 2014 14:49:20 -0800 (PST)
Received: from [] by id 71/5A-11581-FE783845; Sat, 06 Dec 2014 22:49:19 +0000
X-Originating-IP: []
X-StarScan-Version: 6.12.5; banners=-,-,-
X-VirusChecked: Checked
Received: (qmail 16833 invoked from network); 6 Dec 2014 22:49:19 -0000
Received: from (HELO ( by with AES128-SHA encrypted SMTP; 6 Dec 2014 22:49:19 -0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 8.3.348.2; Sat, 6 Dec 2014 22:49:18 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 6 Dec 2014 22:49:18 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id; Sat, 6 Dec 2014 22:49:16 +0000
Received: from ([]) by ([]) with mapi id 15.01.0031.000; Sat, 6 Dec 2014 22:49:16 +0000
From: <>
To: <>
Subject: Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)
Thread-Topic: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)
Date: Sat, 6 Dec 2014 22:49:15 +0000
Message-ID: <>
References: <20141206170611.39377.qmail@ary.lan> <> ,<> <>, <>
In-Reply-To: <>
Accept-Language: en-AU, en-US
Content-Language: en-US
x-originating-ip: []
x-microsoft-antispam: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB460;
x-exchange-antispam-report-cfa-test: BCL:0;PCL:0;RULEID:;SRVR:DB4PR06MB460;
x-forefront-prvs: 0417A3FFD2
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(6009001)(189002)(51704005)(24454002)(199003)(377454003)(122556002)(105586002)(87936001)(230783001)(68736005)(4396001)(66066001)(33656002)(40100003)(99396003)(19580395003)(20776003)(110136001)(19580405001)(77096005)(76576001)(107046002)(21056001)(106356001)(15198665003)(1720100001)(106116001)(31966008)(54206007)(15395725005)(101416001)(77156002)(62966003)(97736003)(64706001)(50986999)(54356999)(120916001)(93886004)(2656002)(74316001)(74482002)(76176999)(86362001)(46102003)(92566001)(54606007)(102836002)(15975445007); DIR:OUT; SFP:1102; SCL:1; SRVR:DB4PR06MB460;; FPR:; SPF:None; MLV:sfv; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 06 Dec 2014 22:49:24 -0000

It's already an exercise in pedantry, and I'm well aware that circulation was on paper copies - hence my comment on 'original', given that it was typed up using some proprietary system. And I'd trust a mimeograph over a newfangled photocopy. All we're doing here is shifting shadows on a wall.

Engineering standards require stable referents; which makes it a valid engineering question.

Security pedants might wonder why there is no easy way to authenticate electronic copies of RFCs, given the vast array of security-related protocols that the IETF has defined. How can I check the integrity of an RFC document and that it hasn't been tampered with? I imagine an MD5sum just won't do.

Lloyd Wood
From: John C Klensin <>
Sent: Sunday, 7 December 2014 9:15:27 AM
To: Wood L  Dr (Electronic Eng)
Subject: Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)

--On Saturday, December 06, 2014 21:13 +0000

> If RFC20 is made a full standard, then references to it must
> be to a particular paper copy (not necessarily the
> 'original'), since there's a chicken-and-egg problem in
> needing to have a working implementation of RFC20 just to
> decode and read electronic transcriptions of RFC20.

Lloyd, if you want to turn this into an exercise in how pedantic
it is possible to get, I'm pretty sure we will all lose.

However, and perhaps ironically, the very early RFCs were
published and circulated on paper and the normative copies were
paper copies.  You could derive strong hints about this from
reading RFC 10 which (with RFC 16) specifies the distribution
list around the time RFC 20 was written and, notable, gives
postal mail addresses and not network ones.  That is
unsurprising since FTP, much less FTP with anonymous/guest and
mail accounts, didn't come along until over a year later.

If you were to look at the early RFCs, you would find notes on
many of them indicating that they were typed back in or
otherwise reconstructed into machine-readable ASCII page image
form some years later.   Some even contain warnings that the
renditions might not be completely accurate.  In particular, if
you look at the current online version of RFC 20, you will find
a note that reads:

        "[ This RFC was put into machine readable form for
        [ into the online RFC archives by Robbie Bennet 9/99]"

As has already been noted, Robbie made an error in constructing
the document footers (I'd have to dig out my copy of the
original (see below) to even figure out of it had footers --
many of the early documents did not) leaving the author as
someone named "Cert".

In addition, I don't know about RFC 20 (and don't know if Vint
would remember), but many of those early documents were produced
in either NLS or the approximately-proprietary word processing
systems of one environment or another, formats that no one (at
least no one I know of or have talked with about this)
considered appropriate for interchange, much less archival, use.
Some were even produced using an ancient technology that I
believe was called "typewriters".

I've had my hands on a photocopy of the original distribution
version of RFC 20 and not only was it on paper but it was
pretty-printed or at least proportionally spaced, not the
page-format ASCII we consider the norm today (or have until
recently).  Don't know where it is at the moment but I could
find it if sufficiently motivated.

> Better to have a dependency outside the RFC series.
> (The silliness of calling anything labelled 'request for
> comments' a standard is now, alas, traditional.)

I am not an engineer and try to avoid getting sucked into
playing one on television (or elsewhere), but I went to school
with engineers and was taught by engineers.  I had always been
taught that good engineering requires pragmatism and attention
to issues that constrained the problem or solution spaces.  From
that point of view, calling an organization in which it is
necessary to have this type of discussion about the details of
reference stability and availability of 45-year-old documents
the "Internet _Engineering_ Task Force" can equally be justified
more by tradition than anything else.  On the other hand, I
really don't think such discussions are needed or helpful, even
(or especially) in the IETF.