+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@xxxxxxx> wrote:
> On 02 Jan 2015, at 14:20, Julian Reschke
> <julian.reschke@xxxxxx> 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
>