Re: [apps-discuss] [Errata Rejected] RFC6365 (4005)

[John C Klensin <[e-mail]>]

Sigh.

Folks, I apologize, but I'm very busy, not feeling well, have
zero support for any IETF-related or
Internet-protocol-development-related work (nothing new -- that
has been the case for more than a decade and is partially my
choice to avoid conflicts of loyalties), and have to prioritize
work.  When I get under pressure to get things done, I tend to
write a little too quickly and leave things out.  On the other
hand, when I put in all the details, people attack me for that.
In the last week (and, less specifically, the last few weeks),
I've also felt, perhaps incorrectly, that issues that affected
the PRECIS and URNBIS WGs, and even some policy issues on which
I've got some special experience or perspective, should take
precedence over a detailed response to the comments about this
proposed erratum.   Before someone asks, submitting it was
consistent with those priorities, promoted by the introduction
of "ASCII7" (a term not covered in 6365) in
draft-ietf-precis-framework.

Given that the hasty and sloppy way in which I wrote the erratum
note caused some justifiably-negative comments and a bit of
confusion, I didn't want to respond to the various notes,
especially Ned's, until I had time to do so adequately.  A
partially-written response has been on my machine, being worked
on at intervals to make it tight and clear, since a few hours
after Ned's note was posted.  I assume it is now OBE and that,
if I want to reopen this, it should be in a new draft erratum
that is written as precisely and in as much detail as I can
manage.

In the interim and partially in my defense, I am perfectly aware
of what a "charset" is and equally aware of the use of
"US-ASCII" in the charset context.  I am also aware of the
difference between a coded character set, encodings, and a
repertoire, including, btw, the fact that none of our normal,
Internet, use of the ASCII repertoire in an eight bit
form/encoding (one of at least two that were in use at one time
and distinct from two seven bit encodings I'm aware of and at
least one nine-bit one) isn't specified anywhere in the ASCII
standard.  That is one of the two reasons I've encouraged the
use of normative references in RFCs to RFC 20 rather than X3.4
(or especially the more recent ANSI/INCITS 4).  I have even
argued that the choice of "US-ASCII" as a charset identifier was
a good idea, precisely because it identified one particular
combination of a CCS and encoding.  That was precisely the "IETF
artifact" I was referring to, obviously without going into
enough detail.   And, if the term "artifact" wasn't chosen
carefully enough from the range of alternatives, I'm sorry, but
note that the proposed erratum was intended (I thought clearly)
more to flag the issue for readers and as a memory aid for any
future update or revision, not as definitive text.

I had thought that 6365 itself clearly explained the
CCS-Encoding-Repertoire-Charset distinctions and that I was
writing in that context. Given the discussion, probably I was
wrong and someone should take another look at that.  I do note
that 6365 does use both "ASCII" and "US-ASCII".  I thought that
had been done consistent with references to the ASCII standard,
repertoire, and CCS and the US-ASCII charset.   On rereading
somewhat over a week ago, I was less convinced that we were
consistent enough about that.  That was another thing that
prompted the erratum posting.  It also helped cause the delay in
responding to last week's comments because I wanted to go back
through 6365, check every use of either term, and identify which
ones were candidates for correction or clarification before
creating more misunderstanding.

So much for that idea.

regretfully,
    john




--On Wednesday, June 11, 2014 02:19 -0700 RFC Errata System
<[e-mail]> wrote:

> The following errata report has been rejected 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
> 
> --------------------------------------
> Status: Rejected
> Type: Editorial
> 
> Reported by: John Klensin <john=[e-mail]>
> Date Reported: 2014-06-04
> Rejected by: Barry Leiba (IESG)
> 
> 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.
>  --VERIFIER NOTES-- 
> (1) It's clear that this is NOT errata: the use of "US-ASCII"
> in the document was quite intentional at the time.
> 
> (2) If (and it's not clear that there's consensus on this) we
> think that "US-ASCII" is not the right term, the right answer
> is to revise the document.  Should that be done, we'd open up
> quite a debate about what terminology is right, and why.
> Simply replacing all occurrences of "US-ASCII" with "ASCII" is
> unlikely to be the answer.  Whatever should happen would be
> more complicated than that.
> 
> --------------------------------------
> 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
>