Re: Status of RFC 20
joel jaeggli <joelja@bogus.com> Sun, 07 December 2014 21:47 UTC
Return-Path: <joelja@bogus.com>
X-Original-To: ietf@ietfa.amsl.com
Delivered-To: ietf@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DABC61A006D for <ietf@ietfa.amsl.com>; Sun, 7 Dec 2014 13:47:50 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x8z3GIUkAgFQ for <ietf@ietfa.amsl.com>; Sun, 7 Dec 2014 13:47:47 -0800 (PST)
Received: from nagasaki.bogus.com (nagasaki.bogus.com [IPv6:2001:418:1::81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AEAF31A004E for <ietf@ietf.org>; Sun, 7 Dec 2014 13:47:47 -0800 (PST)
Received: from mbp.local ([IPv6:2601:9:7680:ec8:c99c:4552:7ee6:89ec]) (authenticated bits=0) by nagasaki.bogus.com (8.14.9/8.14.9) with ESMTP id sB7Lle8x018453 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Sun, 7 Dec 2014 21:47:41 GMT (envelope-from joelja@bogus.com)
Message-ID: <5484CAFC.7090909@bogus.com>
Date: Sun, 07 Dec 2014 13:47:40 -0800
From: joel jaeggli <joelja@bogus.com>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:31.0) Gecko/20100101 Thunderbird/31.0
MIME-Version: 1.0
To: John C Klensin <john-ietf@jck.com>, Barry Leiba <barryleiba@computer.org>, "Black, David" <david.black@emc.com>
Subject: Re: Status of RFC 20
References: <CE03DB3D7B45C245BCA0D24327794936289DC7@MX104CL02.corp.emc.com> <CAC4RtVA10gUzmug4+H5SW2JL4Q7-Yh_ntiqPTswYSUUgXMoczA@mail.gmail.c om> <BB4CB3D8CA03EB4A03FEA99B@JcK-HP8200.jck.com>
In-Reply-To: <BB4CB3D8CA03EB4A03FEA99B@JcK-HP8200.jck.com>
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="ob8m9ehOJr8DoJbgoVjgejT4gkQuX2TUQ"
Archived-At: http://mailarchive.ietf.org/arch/msg/ietf/6am4a2QIyYlBXF25Xb0YPXG4EOM
Cc: ietf@ietf.org
X-BeenThere: ietf@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: IETF-Discussion <ietf.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf>, <mailto:ietf-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ietf/>
List-Post: <mailto:ietf@ietf.org>
List-Help: <mailto:ietf-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf>, <mailto:ietf-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 07 Dec 2014 21:47:51 -0000
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@computer.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 >> > > >
- Gen-ART and OPS-Dir review of draft-ietf-json-tex… Black, David
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Barry Leiba
- RE: Gen-ART and OPS-Dir review of draft-ietf-json… Black, David
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John Levine
- Status of RFC 20 (was: Re: Gen-ART and OPS-Dir re… John C Klensin
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Stewart Bryant (stbryant)
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John C Klensin
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Stephen Farrell
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John C Klensin
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Stephen Farrell
- Re: Status of RFC 20 Brian E Carpenter
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… l.wood
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John C Klensin
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… l.wood
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Dave Cridland
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Barry Leiba
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Patrik Fältström
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Phillip Hallam-Baker
- Re: Status of RFC 20 Carsten Bormann
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Pete Resnick
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: Status of RFC 20 joel jaeggli
- Re: Status of RFC 20 John C Klensin
- Re: Status of RFC 20 joel jaeggli
- RE: [Json] Gen-ART and OPS-Dir review of draft-ie… Black, David
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Tim Bray
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… John Cowan
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… John Cowan
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Nico Williams
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Nico Williams
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Nico Williams
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Nico Williams
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Nico Williams
- Integrity protection for RFCs (was Re: Status of … Nico Williams
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: Status of RFC 20 Nico Williams
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Nico Williams
- Re: Integrity protection for RFCs (was Re: Status… manning bill
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Martin J. Dürst
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… Patrik Fältström
- Re: Cited documents, was Status of RFC 20 John Levine
- RE: Gen-ART and OPS-Dir review of draft-ietf-json… Black, David
- Re: Cited documents, was Status of RFC 20 Dave Crocker
- Re: Cited documents, was Status of RFC 20 Nico Williams
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… John Cowan
- Re: Status of RFC 20 Heather Flanagan (RFC Series Editor)
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Nico Williams
- RE: Gen-ART and OPS-Dir review of draft-ietf-json… Black, David
- Re: Cited documents, was Status of RFC 20 Andrew Sullivan
- Re: Cited documents, was Status of RFC 20 John C Klensin
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Nico Williams
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Matthew Kerwin
- Re: Gen-ART and OPS-Dir review of draft-ietf-json… Nico Williams
- RE: Gen-ART and OPS-Dir review of draft-ietf-json… Black, David
- Re: [Json] Gen-ART and OPS-Dir review of draft-ie… John Cowan
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… Julian Reschke
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… ned+ietf
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John C Klensin
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John C Klensin
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… ned+ietf
- Re: Status of RFC 20 (was: Re: Gen-ART and OPS-Di… John C Klensin