RE: [idn] Renaming "AMC-Z"

[John C Klensin <klensin@jck.com>]

--On Thursday, 04 October, 2001 10:34 -0700 "Paul Hoffman / IMC"
<phoffman@imc.org> wrote:

Martin Duerst wrote...

>>  If we use ACE, quite a bit of the archives of this
>> group will become difficult to read for people who think that
>> ACE is ACM-Z.
> 
> For all three people who read the archive...

Let me say that a little more strongly.    Having spent too much
of my life going back through WG archives trying to figure out
what happened, almost none of them are comprehensible unless one
either reads backwards or understands that terminology and
perceptions about relevance change.  Or, most often, all three.
Remember that we quite often have a group chartered to do a
"foo" protocol and that, as they consider what to do, all sorts
of things are identified as "foo".  Mailing list archives
covering a long period are _always_ "difficult to read";
regardless of whether calling the final result "ACE" is a good
idea, the incremental damage to archive-reading caused by making
that choice is unlikely to be marginally significant.

Also, in the hope of shortening another non-productive thread
(for which neither Paul nor Martin are responsible)...


> ASCII is a standard _encoding_ of characters as bytes: in
> other words, a function from byte strings to character strings.
>...
> ``ASCII'' does not mean ``7-bit.'' It is simply not correct to
> refer to Q-P-style Unicode encodings as ``ASCII compatible.''
> ASCII is not merely a set of numbers; it assigns _characters_
> to those numbers.

"ASCII", as used in the IETF, is quite explicitly X3.4-1968, and
that is, quite explicitly, a seven bit character set.  Sometimes
we say "US-ASCII" to be even more clear but, as far as I know,
every one of the references points to X3.4-1968 and any that
don't are probably errors or sloppy work.

> The correct phrase is ``7-bit compatible.'' The encoded
> strings are compatible with 7-bit channels. That's the point
> of these encodings.

Well, actually, we utilize more of ASCII's rules and definitions
than just the 7 bit restriction.  E.g., we don't permit control
characters in these encodings, and the definition of a "control
character" comes straight from the ASCII spec.  I suppose we
could be really precise and call something an AGCCE (ASCII
graphic character compatible encoding, "graphic character" also
being well-defined in the ASCII spec) or an AISGCE (ASCII
internationally sensitive graphic character compatible
encoding), or its possibly more politically correct equivalents,
IS646BVCE  or IS646BVGCE, since we don't use the national-use
positions in these encodings.  

But I don't know how to pronounce any of those, and don't have
time for this, and suspect that the vast majority of the WG
would prefer useful work and moving IDN forward to having days
or weeks of this debate.

And "7 bit channels" are actually only part of the point.  The
other part has to do with sufficiently unambiguous
representation that the mappings work accurately and
consistently in both directions.  And many things that will go
down a seven bit channel don't have that property.

    john