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

John C Klensin <> Sat, 06 December 2014 03:52 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5D3E01A8AA3 for <>; Fri, 5 Dec 2014 19:52:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.61
X-Spam-Status: No, score=-2.61 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id EwZqVpH0dOQf for <>; Fri, 5 Dec 2014 19:52:03 -0800 (PST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 8E9BE1A8824 for <>; Fri, 5 Dec 2014 19:52:03 -0800 (PST)
Received: from ([] by with esmtp (Exim 4.82 (FreeBSD)) (envelope-from <>) id 1Xx6PR-0000fF-ID; Fri, 05 Dec 2014 22:51:53 -0500
Date: Fri, 05 Dec 2014 22:51:48 -0500
From: John C Klensin <>
To: Barry Leiba <>, "Black, David" <>
Subject: Status of RFC 20 (was: Re: Gen-ART and OPS-Dir review of draft-ietf-json-text-sequence-09)
Message-ID: <>
In-Reply-To: <>
References: <> < om>
X-Mailer: Mulberry/4.0.8 (Win32)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
X-SA-Exim-Scanned: No (on; SAEximRunCond expanded to false
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 03:52:05 -0000

Barry (and IESG generally),

This has come up multiple times and will undoubtedly keep coming
up, especially since RFC 20 is a stable reference to one
particular version of ASCII and actually includes the code
tables while X3.4-1968 (the version to which it refers) is
largely unobtainable today (only the current version is) and
ANSI X3.4, aka ANSI/INCITS 4, is not a stable reference without
a date.

Most, perhaps all, versions of ANSI X3.4 (and ANSI/INCITS 4)
also specify the repertoire and coding, i.e., the CCS, but not
what we would call the encoding form today (in the case of RFC
20, the familiar "seven bits in and eight bit byte with high
order bit always zero").  So, for most IETF purposes, RFC 20
really should be the normative reference for ASCII (or, if one
prefers, "US-ASCII").

RFC 20 has status "Unknown" only because it comes from a time
that predates both the IETF and our use of the term "standard"
(with or without qualifications) to describe Internet technical

So, rather than go through a discussion about downrefs and the
like every time RFC 20 is referenced from a Standards-Track
specification, I suggest that the IESG reclassify it to Internet
Standard and waste as little more time doing so as possible.  

The implementation report is that, whether they explicitly
reference RFC 20 or not, substantially every application-layer
protocol we have depends on the ASCII CCS and encoding form
specified in that RFC.  In addition, RFC 5234 and its
predecessors are heavily dependent on ASCII so that
substantially any specification that depends on ABNF is also an
ASCII implementation.


--On Friday, December 05, 2014 17:38 -0500 Barry Leiba
<> wrote:

> Hi, David.  One note on your review:
>> idnits didn't like the reference to RFC 20 for ASCII:
>>   ** Downref: Normative reference to an Unknown state RFC:
>>   RFC   20
>> RFC 5234 (ABNF) uses this, which looks like a better
>> reference:
>>    [US-ASCII]  American National Standards Institute, "Coded
>>    Character Set -- 7-bit American Standard Code for
>>                Information Interchange", ANSI X3.4, 1986.
> Except that (1) many IETF documents do use RFC 20 and (2) the
> RFC 20 reference is not for ASCII: it's for RS, the Record
> Separator character, which is explained in RFC 20, Section 5.2.
> Barry