Re: Status of RFC 20

On 12/5/14 7:51 PM, John C Klensin wrote:
> 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
> specifications.
>
> 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.  
3967 applies quite effectively

   Once a specific down reference to a particular document has been
   accepted by the community (e.g., has been mentioned in several Last
   Calls), an Area Director may waive subsequent notices in the Last
   Call of down references to it.  This should only occur when the same
   document (and version) are being referenced and when the AD believes
   that the document's use is an accepted part of the community's
   understanding of the relevant technical area.  For example, the use
   of MD5 [RFC1321] and HMAC [RFC2104] is well known among
   cryptographers.

Anyone raising downref issues with rfc 20 is out of their mind.

that said you'll note a rather large gap in citations, given that for
something like 29 of the last 45 years there wasn't an online copy in
the rfc repository.

http://www.arkko.com/tools/allstats/citations-rfc20.html
> 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.
>
> Thanks,
>     john
>
>
> --On Friday, December 05, 2014 17:38 -0500 Barry Leiba
> <barryleiba(_at_)computer(_dot_)org> 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

signature.asc
Description: OpenPGP digital signature