Subject: [apps-discuss] [Editorial Errata Reported] RFC6365 (4005)

From: RFC Errata System <[email-masked]>
Date: Wed, 4 Jun 2014 13:32:55 -0700 (PDT)

The following errata report has been submitted for RFC6365,
"Terminology Used in Internationalization in the IETF".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=6365&eid=4005

--------------------------------------
Type: Editorial
Reported by: John Klensin <john=[email-masked]>

Section: GLOBAL

Original Text
-------------
US-ASCII

Corrected Text
--------------
ASCII

Notes
-----
The term "US-ASCII" is an IETF artifact, left over from some misunderstandings about what "ASCII" referred to (and the complete absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded character sets).  It is a source of confusion for people who come to IETF specifications with a background in coded character sets and terminology from other areas or standards bodies and has been warned against multiple times.  It should not have appeared in this document except possibly with a warning against its use (and the use of other bogus terms like "ASCII7").  The second author, who is normally sensitive to the issue, has no idea how this got past him, even in text picked up from other documents, but supposes this is what errata are for.

In any event, there is no such thing as "US-ASCII": the term is an erroneous and misleading synonym/ substitute for "ASCII".  The reference for the latter is correct, but the citation anchor should probably be corrected as well.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC6365 (draft-ietf-appsawg-rfc3536bis-06)
--------------------------------------
Title               : Terminology Used in Internationalization in the IETF
Publication Date    : September 2011
Author(s)           : P. Hoffman, J. Klensin
Category            : BEST CURRENT PRACTICE
Source              : Applications Area Working Group
Area                : Applications
Stream              : IETF
Verifying Party     : IESG

---

From: Barry Leiba <[email-masked]>
Date: Wed, 4 Jun 2014 16:52:34 -0400

John, your argument may well be absolutely correct, but this is also
absolutely *not* an error in the specification.  You and Paul
certainly *meant* to say "US-ASCII", and, while in retrospect perhaps
you shouldn't have, it's not an issue for an errata report.

Am I wrong here?

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Wed, 4 Jun 2014 14:05:48 -0700

I'm not sure how to deal with this errata. grep tells me that the term "US-ASCII" appears to have been invented in the first MIME specs, starting with RFC 1341. The reference to it is just the ANSI spec, which does not appear to have "US-ASCII" in the title.

However, grep also tells me that the term appears in about 370 RFCs. I propose that trying to change it now would be indistinguishable from a DoS attack on the RFC errata system.

A proposed counter-proposal for this would be as follows.

Section: New section 1.4 to be added

Original Text
-------------
(none)

Corrected Text
--------------
Throughout this document and hundreds of other RFCs, the term "US-ASCII" is used in text and in references to refer to the coded character set defined by ANSI as "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986". Although the term "US-ASCII" has been popular for more than two decades, it is incorrect: it should just be called "ASCII". There is no "US-ASCII" defined, and using the "US-" prefix can cause confusion to readers who wonder what that prefix means.

If the chairs/ADs agree with this, you should reject John's errata and I'll submit mine with any edits you like.

As a side note:

On Jun 4, 2014, at 1:32 PM, RFC Errata System <[email-masked]> wrote:

> The second author, who is normally sensitive to the issue, has no idea how this got past him, even in text picked up from other documents, but supposes this is what errata are for.

The second author did not contact the first author before submitting this errata. Further, the first author notes that the second author has used the term in many of said second author's earlier RFCs. Further, the first author disagrees that this is what errata is for.

--Paul Hoffman

---

From: Ned Freed <[email-masked]>
Date: Wed, 04 Jun 2014 14:46:58 -0700 (PDT)

This errata may represent the way you would like things to be, it's factually
incorrect and doesn't represent the way things are.

"US-ASCII" is the registered charset name for what's defined in ANSI X3.4-1986.
Not "ASCII". It's the charset various important media types default to, and
it's the name that appears  throughout RFC 2046 as well as many other RFCs. And
if you use any other name for this charset, including but not limited to plain
"ASCII", you're not going to like the results.  As such, there absolutely is
such a thing a "US-ASCII" and it's far more than an "IETF artefact" at this
point.

Les jeux sont faits, rein ne va plus.

I note in passing that the text in RFC 6365 is incorrect in another way: It
effectively says that "charset" and "character encoding scheme" are equivalent.
They aren't. A charset is, as RFC 6365 correctly says, a mapping from a
sequence of octets to a sequence of characters. A character encoding scheme
(CES), OTOH, is a means of translating a sequence of integers into a sequence
of octets. And a coded character set (CCS) is a 1:1 mapping between a set of
characters and a set of integers.

When you combine one or more  CCSes and a CES you obtain a means of translating 
from characters to octets. This is the inverse of a charset, more or less.

Charset was defined the way it was because we very consciously and deliberately
*rejected* the ISO approach to this stuff when MIME was specified. The main
problem with the CCS/CES thing is that it's inherently ambiguous: For example,
if even a subset of ISO 2022 is part of your CES, you now have a one-to-many
mapping - and an interoperability mess in the making.

Charset, on the other hand, is clean, simple and precise. It focuses on
interpretation rather than creation of the octet stream, which is what you want
when interoperability is your primary goal.

As always, the proof is in the pudding. There are any number of examples of the
suckage of the ISO approach to this problem - generaltext anyone? - but the one
I like to use is the combination of RFC 1468 and RFC 2047. In brief, RFC 1468
says that you can't have two adjacent double byte segments. RFC 2047 then says
that any such segment must be entirely enclosed in an encoded-word. It also
says that spaces (which would count as a single byte segement) between encoded
words are to be removed. Which, unless you go to a lot of trouble to remove the
single-byte-seq double-byte-seq pairs, results in illegal iso-2022-jp.

This is what happens when you use an overly complex approach built on decades
of accreted bad design.

Now, as you might have already guessed, my sympathy level for the poor ISOers
who are confused by the approach the IETF took to this problem is low.
Actually, make that nonexistant. The character set space is a huge mess in
large part due to the way the ISO has handled it.

And like it or not, failure has consequences. The "US-ASCII" label is one of
them.

				Ned

> > The term "US-ASCII" is an IETF artifact, left over from some
misunderstandings about what "ASCII" referred to (and the complete absence of
CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and other "American" coded
character sets).  It is a source of confusion for people who come to IETF
specifications with a background in coded character sets and terminology from
other areas or standards bodies and has been warned against multiple times.  It
should not have appeared in this document except possibly with a warning
against its use (and the use of other bogus terms like "ASCII7").  The second
author, who is normally sensitive to the issue, has no idea how this got past
him, even in text picked up from other documents, but supposes this is what
errata are for.

> > In any event, there is no such thing as "US-ASCII": the term is an
erroneous and misleading synonym/ substitute for "ASCII".  The reference for
the latter is correct, but the citation anchor should probably be corrected as
well.

> _______________________________________________
> apps-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/apps-discuss

---

From: S Moonesamy <[email-masked]>
Date: Fri, 06 Jun 2014 09:08:13 -0700

At 13:32 04-06-2014, RFC Errata System wrote:
>misunderstandings about what "ASCII" referred to (and the complete 
>absence of CSCII or CASCII, MSCII or MXSCII, BRSCII, ARSCII, and 
>other "American" coded character sets).  It is a source of confusion 
>for people who come to IETF specifications with a background in 
>coded character sets and terminology from other areas or standards 
>bodies and has been warned against multiple times.  It should not 
>have appeared in this document except possibly with a warning 
>against its use (and the use of other bogus terms like 
>"ASCII7").  The second author, who is normally sensitive to the 
>issue, has no idea how this got past him, even in text picked up 
>from other documents, but supposes this is what errata are for.
>
>erroneous and misleading synonym/ substitute for "ASCII".  The 
>reference for the latter is correct, but the citation anchor should 
>probably be corrected as well.

I read ANSI X3.4-1986.  The term for the Coded Character Set is 
"ASCII".  The character set in the IANA registry is "US-ASCII".  Ned 
Freed commented about that.  The term "USASCII" predates the IETF.  I 
took a quick look at several IETF RFCs and found occurrences of the 
term "US-ASCII".

I suggest not doing a global replace as the two terms are not used 
interchangeably throughout RFC 6365.

The guidance which people might be following could be:

   "These are the official names for character sets that may be used in
    the Internet and may be referred to in Internet documentation.  These
    names are expressed in ANSI_X3.4-1968 which is commonly called
    US-ASCII or simply ASCII.  The character set most commonly use in the
    Internet and used especially in protocol standards is US-ASCII, this
    is strongly encouraged.  The use of the name US-ASCII is also
    encouraged."

Regards,
S. Moonesamy

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Jun 2014 09:37:38 -0700

On Jun 6, 2014, at 9:08 AM, S Moonesamy <[email-masked]> wrote:

> The term "USASCII" predates the IETF.

Do you have examples of that? I could not find any, but I might have missed them.

--Paul Hoffman

---

From: Hector Santos <[email-masked]>
Date: Fri, 06 Jun 2014 13:12:02 -0400

> Do you have examples of that? I could not find any, but I might have missed them.

Ask former device driver developers what they were using and before 
they started or with the IETF.  I was referencing US-ASCII charts in 
my early 80s ANSI, VT10x, display, dot/laser printer device drivers, 
flow control, data communications, text/gui editor design works.  This 
charts came from non-IETF documents like from hardware or software 
vendor reference manuals, which probably just copied standard charts 
and whether they were named ASCII or US-ASCII, it was pretty obvious 
we were only dealing or interested with the US or american version of 
printable and non-printable control keys. China and wider 
international support was still far from our minds, and if it was, for 
some, it was a complex and moving target implementation problem. We 
were also very still influence with 7-bit text based application needs.

As for a public example, I see one at wikipedia.  The attached image 
would be a common chart seen in many materials, this is is circa 1972.

http://en.wikipedia.org/wiki/File:ASCII_Code_Chart-Quick_ref_card.jpg

-- 
HLS

---

From: S Moonesamy <[email-masked]>
Date: Fri, 06 Jun 2014 10:11:45 -0700

Hi Paul,
>Do you have examples of that? I could not find any, but I might have 

The term is used in RFC 20.

Regards,
S. Moonesamy

---

From: "John Levine" <[email-masked]>
Date: 6 Jun 2014 17:30:19 -0000

>Do you have examples of that? I could not find any, but I might have missed them.

Here's a blurb from 1973 for a TI terminal that says it speaks USASCII:

http://bitsavers.trailing-edge.com/pdf/ti/terminal/TI-334A-10M_Silent_700_Model_732_733_Specifications_Jul_1973.pdf

---

From: "John Levine" <[email-masked]>
Date: 6 Jun 2014 17:40:22 -0000

>Do you have examples of that? I could not find any, but I might have missed them.

One more: US Patent 3,743,797, filed on Aug 30, 1971 by a guy at Bell
Labs for a keyboard decoding matrix says in columns 8 and 9:

 The principles of this invention can be used in a key
 board which, along with some simple logic circuitry,
 can be utilized to generate special codes such as the
 United States American Society for Communication
 and Information Interchange Code (USASCII Code).
 Because the USASCII Code contains 128 elements, a
 (4 X 4) matrix using second-order stroke coding is suf-
 ficent to generate the complete code because as previ-
 ously mentioned such a matrix can define up to 256
 unique characters.

Googling around I see a lot of references from the early 1970s.  The
earliest I see is a Burroughs document at bitsavers from May 1970.

R's,
Prior Art 'r' Us

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Jun 2014 15:52:50 -0700

Thanks for the pointers to earlier reference to USASCII and US-ASCII. I still believe that John's propose errata should be rejected, and replaced with something along the lines of the following:

Section: New section 1.4

Original Text
-------------
(none)

Corrected Text
--------------

1.4 Use of "US-ASCII"

Throughout this document and hundreds of other RFCs, the term "US-ASCII" is used in text and in references to refer to the coded character set defined by ANSI as "Coded Character Set -- 7-bit American Standard Code for Information Interchange, ANSI X3.4-1986". Although the term "US-ASCII" has been popular in RFCs for more than two decades, and in non-IETF usage before that, it is probably not the best term to use: it should just be called "ASCII". The ANSI reference does not define "US-ASCII", and using the "US-" prefix can cause confusion to readers who wonder what that prefix means.

---

From: Barry Leiba <[email-masked]>
Date: Fri, 6 Jun 2014 19:17:32 -0400

> I still believe that John's propose errata should be rejected,

I agree.

> and replaced with something along the lines of the following:

I don't agree.  The use of "US-ASCII" in RFC 6365 was not an error
that failed to be caught.  We all looked at it, and we all thought it
was a fine term to use.  In fact, many thought it preferable to
"ASCII" in the context.  That we might think otherwise now is not
correct use of the errata system.

> Section: New section 1.4
>
> Original Text
> -------------
> (none)
>
> Corrected Text
> --------------
>
> 1.4 Use of "US-ASCII"
>
> Throughout this document and hundreds of other RFCs, the term
> "US-ASCII" is used in text and in references to refer to the coded
> character set defined by ANSI as "Coded Character Set -- 7-bit
> American Standard Code for Information Interchange, ANSI X3.4-1986".
> Although the term "US-ASCII" has been popular in RFCs for more than
> two decades, and in non-IETF usage before that, it is probably not the
> best term to use: it should just be called "ASCII". The ANSI reference
> does not define "US-ASCII", and using the "US-" prefix can cause
> confusion to readers who wonder what that prefix means.

If you would like to write a one-page draft that "updates" 6365 and
that says that, I will be happy to AD-sponsor it.

Barry

---

From: Paul Hoffman <[email-masked]>
Date: Fri, 6 Jun 2014 16:23:50 -0700

> that says that, I will be happy to AD-sponsor it.

If John wants to do so, great. I guess I'll co-author if he does. Otherwise, maybe we can just let this one die.

--Paul Hoffman

---

From: Nico Williams <[email-masked]>
Date: Fri, 6 Jun 2014 18:26:29 -0500

Give it a generic title, something like, "It's ASCII, not US-ASCII".

---

From: Ned Freed <[email-masked]>
Date: Fri, 06 Jun 2014 16:51:20 -0700 (PDT)

> took a quick look at several IETF RFCs and found occurrences of the

That's a very good point I should have remembered, the more fool I for not
having done so. The term "ASCII" as defined X3.4 is NOT a charset. So it's
actually incorrect to use them interchangeably.

> interchangeably throughout RFC 6365.

You're right. The terms are used for the most part correctly, but there are
some goofs, e.g. the reference label [US-ASCII] should be [ASCII], or better
still something like [ANSI-X3.4]. And most of the places where it says
"non-ASCII text" should be "non-US-ASCII text", because there are many CESes
that can be combined with the ASCII CCS, and a lot of them don't produce
anything resembling what's being talked about here.

This goes far beyond the ability of an erratum to fix, I think.

>     is strongly encouraged.  The use of the name US-ASCII is also

It needs to be "charset", not "character set", but other than that
this looks OK to me - as far as it goes.

				Ned

---

From: Ned Freed <[email-masked]>
Date: Sat, 07 Jun 2014 08:06:51 -0700 (PDT)

> was a fine term to use.

Actually, it's more than that. We thought it was the *correct* term to
use.

> In fact, many thought it preferable to

Again, more than that. At least some of us thought that the use of the term
"ASCII" would have been *incorrect*.

> that says that, I will be happy to AD-sponsor it.

And this is supposed to accomplish ... what, exactly? We have two different
terms that refer to different things. We have now apparently decided that one
of these terms is "confusing" and wish to deprecate its use in favor of the
other.

This despite the fact that the terms aren't interchangeable, and the one we
wish to deprecate is actual registered name for the entity we're referring to
most of the time. Which means this change is likely to cause, well, a lot of
confusion.

And this is somehow supposed to make things "better".

I guess "better" got redefined when I wasn't looking.

If you want to fix something, fix the actual problems RFC 6365 has.
Unfortunately that's not really amenable to being done in either an erratum or
a separate document. I don't see any way to do it other than a full revision,
which is likely to open multiple cans of worms.

				Ned

---

From: "Martin J. Dürst" <[email-masked]>
Date: Mon, 09 Jun 2014 16:18:14 +0900

I have read the original erratum post and all the followup posts. I have 
also looked through RFC 6365 searching for all occurrences of the string 
ASCII (which of course includes strings reading US-ASCII).

I fully agree with what Ned wrote below (up to and including the 
paragraph that starts with "If you want to fix something, fix the actual 
problems RFC 6365 has.").

I also think that the way the RFC is currently written, the chance that 
a reader from another area or standard body is fundamentally confused 
(rather than just confused for a short time) is quite low.

Regards,    Martin.