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

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2015 14:20:30 +0100

On 2014-12-31 21:38, Elwyn Davies wrote:
> Hi.
>
> There are a number of references to "appendices" in this document  -
> Section 4.2 (footnotes 2 and 3) and Section 6.5, but the version of RFC
> 20 available online at http://www.rfc-editor.org/rfc/rfc20.txt does not
> have any appendices.
>
> It is possible that this is because the appendices were not reproduced
> when the document was put into machine readable form in 1999.  After
> some research, I suspect that in fact the references are to the
> appendices of the American National Standard (ANSI) X3.4-1968 - the
> references in the Section 4.2 footnotes to Appendices A5.2 and B4 almost
> certainly are.  I was unable to access a copy of the original 1968
> version of ANSI X3.4 (it appears that there are copies in the Library of
> Congress and the library at the University of Wisconsin but it's a long
> walk ;-) ). However, I found a facsimile of the 1986 version.  It is
> clear that Appendices A5.2 and B5 (as opposed to B4) contain relevant
> material (the 1977 update was apparently a very minor affair).
>
> If indeed the second case is correct and the RFC document never had any
> appendices, I suggest that an addition is made to the colophon to point
> out where the appendices can be found, that is ANSI X3.4-1968.  This
> doesn't quite cover the wording in Section 6.5 - are we allowed to alter
> this to point to the appendices of   ANSI X3.4-1968?
>
> If the original of RFC 20 did indeed contain these appendices, fixing
> the issue is a bit more tedious.
>
> Happy New Year,
> Elwyn

As attractive it might be to re-classify RFC 20, maybe it's better to 
actually work on a rfc20bis?

Best regards, Julian

---

From: Carsten Bormann <[email-masked]>
Date: Fri, 2 Jan 2015 16:13:09 +0100

On 02 Jan 2015, at 14:20, Julian Reschke <[email-masked]> 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

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2015 16:27:42 +0100

On 2015-01-02 16:13, Carsten Bormann wrote:
> ...

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

---

From: John C Klensin <[email-masked]>
Date: Fri, 02 Jan 2015 11:04:55 -0500

+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
<[email-masked]> wrote:

> 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
>

---

From: [email-masked]
Date: Fri, 02 Jan 2015 08:23:54 -0800 (PST)

> 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.

I would characterize it as letting the perfect be the enemy of the more than
good enough, but regardless, it's SSDD.

				Ned

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Jan 2015 11:10:51 -0600

On Fri, Jan 02, 2015 at 11:04:55AM -0500, John C Klensin wrote:
> old spec is not likely to be fruitful.  [...]

+1.  Especially given how useful RFC 20 is.

Let's demonstrate agility and pragmatism here.  Promote RFC 20 after a
small effort to ascertain the RFC-Editor's current electronic version's
faithfulness to such "original" paper copies as might be found.  Or even
*without* such an effort: publish any errors found later as errata and
call it a day.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2015 19:17:16 +0100

> *without* such an effort: publish any errors found later as errata and

So we're supposed to make a decision over a document we currently can't see?

Best regards, Julian

---

From: "John Levine" <[email-masked]>
Date: 2 Jan 2015 18:33:13 -0000

>So we're supposed to make a decision over a document we currently can't see?

No, we're going to make the online version of RFC 20 a standard, since
in practice that's what it is now, and then we can use the time we
don't spend rewriting it to do useful work.

We all realize that the appendices aren't there.  Since we've done
without them at least for the 15 years that the current version has
been on line, what problem will be solved by spending effort to find
or reconstruct them?

R's,
John

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Jan 2015 07:46:19 +1300

> *without* such an effort: publish any errors found later as errata and

Let's just exhibit the common sense that used to be a characteristic
of the IETF: attach the correct status (Internet Standard) to this
document, which we'd have done 20 years ago without any fuss if we'd
thought of it then, and be done with it.

Why are we even discussing anything else? Elwyn noted a minor bug in
the text, and he knows how to submit an erratum.
(I've consulted RFC20 a zillion times, without the slightest need
to look at the phantom appendices.)

    Brian

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Jan 2015 12:51:17 -0600

On Fri, Jan 02, 2015 at 07:17:16PM +0100, Julian Reschke wrote:
> >Let's demonstrate agility and pragmatism here.  Promote RFC 20 after
> >a small effort to ascertain the RFC-Editor's current electronic
> >version's faithfulness to such "original" paper copies as might be
> >found.  Or even *without* such an effort: publish any errors found
> >later as errata and call it a day.
> 

I can see the RFC-Editor's electronic copy.  Can't you?

I'm saying: call the RFC-Editor's electronic copy of RFC 20 _the_
canonical copy, promote it to Standard, and publish any errata we can
find (e.g., the author's name).

Later we can do an RFC 20bis if we really have to, but I'm hoping we
won't have to, mostly because there are better things to work on.

Nico
--

---

From: Julian Reschke <[email-masked]>
Date: Fri, 02 Jan 2015 22:04:40 +0100

> I can see the RFC-Editor's electronic copy.  Can't you?

I can. Is this the document we are discussing, or is it the paper copy? 
Can somebody check both for differences=

> find (e.g., the author's name).

I'm ok with that if we agree about it.

Best regards, Julian

---

From: Nico Williams <[email-masked]>
Date: Fri, 2 Jan 2015 15:09:49 -0600

On Fri, Jan 02, 2015 at 10:04:40PM +0100, Julian Reschke wrote:
> I can. Is this the document we are discussing, or is it the paper
> copy? Can somebody check both for differences=

This is the only document we ought to be discussing, as it's the copy
the RFC-Editor has "published" at this time for all intents and purposes
(yes, a different version was once available samizdat-style, but for
today's purposes, the copy that the RFC-Editor *has* on hand *is* the
canonical).

At least barring the RFC-Editor finding a better copy _soon_ and telling
us soon also.  Arguably it's too late for that.

Any paper copies should be for errata purposes only.

> I'm ok with that if we agree about it.

Me too.

Nico
--

---

From: Harald Alvestrand <[email-masked]>
Date: Sat, 03 Jan 2015 12:09:16 +0100

> to look at the phantom appendices.)

Errata for the win!

An erratum saying "the text points to appendixes that are actually in
the ANSI standard it talks about" should be sufficient.

Showing that the IETF is a pragmatic organization is, IMHO, more
important than finding those appendixes.

---

From: Måns Nilsson <[email-masked]>
Date: Sat, 3 Jan 2015 16:47:38 +0100

> important than finding those appendixes.

++;

-- 
Måns Nilsson     primary/secondary/besserwisser/machina
MN-1334-RIPE                             +46 705 989668
FEELINGS are cascading over me!!!

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2015 18:08:08 -0000

>the ANSI standard it talks about" should be sufficient.

Done.  This makes two errata I have submitted for this RFC, which
should be enough.

R's,
John

---

From: "John Levine" <[email-masked]>
Date: 3 Jan 2015 19:26:33 -0000

>>the ANSI standard it talks about" should be sufficient.

By the way, I don't have a copy of X3.4-1968, but I do have a copy of
X3.4-1977, which says in the back that it's a minor revision of the
1968 edition.  The two footnotes on page 5 appear unchanged in the
1977 edition, other than that appendix B4 is now B5, and I can assure
you that you haven't missed anything you didn't already know.

R's,
John

---

From: David Farmer <[email-masked]>
Date: Sat, 3 Jan 2015 19:42:52 -0600

> On Jan 3, 2015, at 13:26, John Levine <[email-masked]> wrote:

Give that reference copies of x3.4-1968 are few and far between and I don't believe are available electronically anywhere other than RFC 20 itself, I would like to suggest a note in the erratum translating the appendix pointers to x3.4-1977 and that the current version x3.4-1986 contains the differences between it and x3.4-1977.

FYI, an unofficial version of x3.4-1965 was is published in; Communications of the ACM, Volume 8 Issue 4, April 1965, Pages 207-214 and available electronically at;

http://dl.acm.org/citation.cfm?id=363839

The article discusses in detail the differences between the proposed version and x3.4-1963. The differences between x3.4-1965 and x3.4-1968 are relatively obvious when you compare the text of RFC 20 with the text in the article, and also easily provides the gist of the x3.4-1968 appendices not provided in RFC 20.

I hope we can put this to bed and promote RFC 20 officially the Internet Standard status it deserves and for all intensive purposes that it is and has been for over 45 years.  Further, I support the erratum with the translation to x3.4-1977 as noted above and the correction to the obvious OCR errors in the reference to x3.4-1968 and the author's name, however humorous they are.

Thanks.
-- 
===============================================
David Farmer               Email:[email-masked]
Networking & Telecommunication Services
Office of Information Technology
University of Minnesota    
2218 University Ave SE        Phone: 612-626-0815
Minneapolis, MN 55414-3029   Cell: 612-812-9952
===============================================

---

From: "John Levine" <[email-masked]>
Date: 4 Jan 2015 01:59:27 -0000

>Give that reference copies of x3.4-1968 are few and far between and I don't believe are
>available electronically anywhere other than RFC 20 itself, I would like to suggest a note in
>the erratum translating the appendix pointers to x3.4-1977 and that the current version
>x3.4-1986 contains the differences between it and x3.4-1977.

The current version appears to be ANSI INCITS 4-1986 (R2007).  Copies,
probably all unauthorized, are easy to find on the web.  It's still not
very different from the earlier versions.

Since the appendices in question say nothing of importance, I think we
have spent far too much time on this already.

R's,
John

---

From: Stephen Farrell <[email-masked]>
Date: Sun, 04 Jan 2015 02:20:30 +0000

> have spent far too much time on this already.

Isn't that what we always do? If someone had good ideas as to
how to decrease that kind of self-flagellation I'd be interested
and happy to try push those along. But please send those to me
off-list for now, an on-list discussion on this topic will most
likely end up 99% guff no matter how hard we each try to keep it
sensible. (I think part of our problem is that there are so many
of us and on any one topic some small few of us fall for the
"but I really have to reply this time" fallacy that that's always
going to make us make us look collectively dim;-)

Ta,
S.

---

From: Tony Hansen <[email-masked]>
Date: Mon, 05 Jan 2015 01:23:23 -0500

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