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 http://about.me/lloydwood ________________________________________ From: John C Klensin <john-ietf@xxxxxxx> Sent: Sunday, 7 December 2014 9:15:27 AM To: Wood L Dr (Electronic Eng) Cc: ietf@xxxxxxxx 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 l.wood@xxxxxxxxxxxx wrote: > 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 entry] [ 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. john