Subject: Re: [idn] Is The IDN WGroup Still Active? Fwd: [IDNList] Registrar

From: [email-masked]
Date: Wed, 3 Oct 2001 12:52:26 -0700

I am thinking this FYI is important for the users and 
administrators to be aware of if the WG go with any 
laguage tagged scheme at all.  Since: 

It may lead to inconsistent exception conditions due to 
changes in language specific normalization procedure. 
 For example, a UCS code point A in language tag T is 
excluded in Version X, as there is no blocking for any 
UCS code points in place yet.  Due to upgrade Version X+1, 
T(A) has been newly included tagged code blocks, then
 an input contains A  fail in Version X, but will succeed
 in Version X+1.  Due to failure in X will be coded with a 
defaulted ACE as a legal name, then the same input 
will not be fail in X+1, an inconsistency will resulted. 

If the WG has consensus on NOT using language tag
mechanism, it is better to voice this and let 
VeriSign users go ahead.

I am upgrade idn-map draft  to address this problem
 too, I need to know the above too, so that I don't 
need work for this group any more. Thank you all  for
saving my time.

Liana 

On Fri, 28 Sep 2001 16:18:12 -0400 [email-masked] (J. William Semich)
writes:
> Haven't heard anything on the IDN list since Sept 1, so I'm wondering 
> if
> maybe the list has gone dark?
> 
> FYI, this just in from Verisign
> 
> -- Bill Semich
> 
> 
> >X-Authentication-Warning: imx3.pvt.lks.verisign-grs.net: majordomo 
> set
> >sender to [email-masked] using -f
> >Reply-To: <[email-masked]>
> >From: "VeriSign Global Registry Services" <[email-masked]>
> >To: <[email-masked]>
> >Subject: [IDNList] Registrar Advisory: AMC-ACE- Z in the zones
> >Date: Fri, 28 Sep 2001 14:10:00 -0400
> >X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0)
> >Importance: Normal
> >Sender: [email-masked]
> >X-MIME-Autoconverted: from 8bit to quoted-printable by 
> verisign-grs.com
> id
> >OAA23352
> >
> >To All IDN-Certified Registrars:
> >
> >VeriSign Global Registry Services (GRS) intends to move forward in 
> the
> >Internationalized Domain Name Testbed by placing the IDNs directly 
> into
> the
> >.com, .net and .org zones.  The zones will be populated with the
> AMC-ACE-Z
> >v0.3.1 representation of the IDNs.  Registrars do not need to 
> modify
> any of
> >their current registration processes to support this change.  All
> existing
> >IDNs originally registered with RACE will be valid under the 
> AMC-ACE-Z
> >encoding.
> 
> <snip>
> 
> 
> 
> 
>

---

From: "James Seng/Personal" <[email-masked]>
Date: Thu, 4 Oct 2001 09:57:41 +0800

> will not be fail in X+1, an inconsistency will resulted. 

See nameprep-08. it is discussed extensively how to deal with
this situation.
 
> mechanism, it is better to voice this and let 

dont see how verisign testbed have anything to do with idn wg.
please keep things in focus.

-James Seng

---

From: "ben" <[email-masked]>
Date: Thu, 4 Oct 2001 00:51:21 -0400

Hi Adam,

>
> I usually don't like acronyms, but ACE is not bad.  I never like
> acronyms that are misspellings of real words, so I'd rather not use
> BACE, CHACE, or SUITCACE.
>
> AMC
>

How about GRACE?  GRACE is *not* a misspelling of real words.  NO...
no... not because my mother is called "Grace" and I want to name
something after her.

But... "With GRACE (defined as god's free and underserved favor to and
love for mankind) the world will become one."

Thanks,
Ben Chan

---

From: "ben" <[email-masked]>
Date: Thu, 4 Oct 2001 09:33:46 -0400

Forgot to say that GRACE stands for "Greatly Reduced ASCII Compatible
Encoding".

By the way, here is another definition:

"With GRACE (defined as a thing of beauty that is with pleasing or
agreeable quality) the world will become one."

Thanks
Ben Chan

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Oct 2001 15:26:30 -0000

ASCII is a standard _encoding_ of characters as bytes: in other words, a
function from byte strings to character strings.

ASCII specifies that, for example, the byte string 100 122 45 45 102 111
111 represents the character string dz--foo.

UTF-8 is compatible with ASCII. The UTF-8 function, restricted to ASCII
byte strings, is exactly the ASCII function. 100 122 45 45 102 111 111
means dz--foo under UTF-8, just as it does under ASCII.

In contrast, if an encoding maps 100 122 45 45 102 111 111 to something
other than dz--foo, that encoding is _not_ compatible with ASCII.

``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.

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

---Dan

---

From: Dave Crocker <[email-masked]>
Date: Thu, 04 Oct 2001 09:22:16 -0700

>compatible with 7-bit channels. That's the point of these encodings.

30 years of consistent use tends to carry more weight than a single 
person's recent desire to impose linguistic changes.

And it is difficult to imagine how this line of discussion is in any way 
seriously helpful to the IDN working group reaching closure.

d/

----------
Dave Crocker  <mailto:[email-masked]>
Brandenburg InternetWorking  <http://www.brandenburg.com>
tel +1.408.246.8253;  fax +1.408.273.6464

---

From: "D. J. Bernstein" <[email-masked]>
Date: 4 Oct 2001 16:58:02 -0000

> person's recent desire to impose linguistic changes.

You are making a fool of yourself, Dave.

As you can easily see from a web search, people consistently and
correctly refer to 8859-1, KOI-8, UTF-8, etc. as being ASCII-compatible.
This includes the authors of RFC 2376, RFC 2445, RFC 3023, the Linux
UTF-8 manual page, etc.

Meanwhile, people consistently and correctly refer to Baudot, for
example, as being incompatible with ASCII, even though Baudot fits
inside 7 bits with room to spare.

The use of ``ASCII'' to mean ``7-bit'' is a silly mistake in some recent
IETF documents: specifically, RFC 2130 and this group's ``ACE'' garbage.
Now that the error has been pointed out, it can easily be fixed.

---Dan

---

From: "Soobok Lee" <[email-masked]>
Date: Fri, 5 Oct 2001 09:14:57 +0900

----- Original Message ----- 
From: "D. J. Bernstein" <[email-masked]>
 
> Now that the error has been pointed out, it can easily be fixed.
 
I  agree on dropping out "ASCII-compatible".
Rather, I suggest to use "ASCII coded" or "ASCII coding".

As Adam pointed out, it will be useful to have two seperate names for
  "bq--xxxxxx" and its subpart "xxxxxx".

Suggestion: for an unicode label A, the conversion of A into
the "xxxxxx"  is called as BOOTSTRING-646.
 
And the one into "bq--xxxxxx"   is  called  in IDN context  as
  "ACUD" (ASCII Coding of Unicode Domain) or
  "ACUL" (ASCII Coding of Unicode Label ) or
  "UTF-LDH".

Soobok Lee

---

From: Dave Crocker <[email-masked]>
Date: Thu, 04 Oct 2001 17:58:57 -0700

>You are making a fool of yourself, Dave.

Gosh.  This is the first time.

For both of us, no doubt.

>Now that the error has been pointed out, it can easily be fixed.

We could, perhaps, have an extended side debate about the relative 
seriousness of making a fool of oneself, versus making a point of 
demonstrating aggressive (and, of course, hostile) ignorance of history.

"We could do it, but it would be wrong."  (Nixon was undervalued as a 
system engineer.)

The Internet use of the terms "ASCII" and "7-bit ASCII" are short-form for 
the complete, 1973 Telnet label of:

         7-bit ASCII
         in an 8-bit field
         with the 8th bit off.

Dick Clark's crew would give it a 9.  You CAN dance to it.  And it shows 
that Internet geeks were into rap long before hip hop came along.

Such short-hand notations are common, convenient, and valid.  Even you use 
them.  It is well understood that when you make ad hominems, whatever words 
you choose really serve as a reflexive shorthand for communicating your own 
insecurities.  Failure to accommodate disagreement has occupies bulky 
tomes.  We do not need to read them.  Your terse ad hominems provide all 
the insight one might otherwise get from extensive reading.

At any rate, Dan, feel free to rail against the weight of linguistic 
convention in this community.  It will be a nice distraction for you, and 
will thereby allowing others to get some real work done.

d/

----------

---

From: Martin Duerst <[email-masked]>
Date: Tue, 09 Oct 2001 18:05:25 +0900

>person's recent desire to impose linguistic changes.

Hello Dave,

I think Dan has a certain point in making a difference between
ASCII-compatible and 7-bit compatible, or between characters and
bytes in general. Even 30 years of continued (not consistent)
use doesn't change the fact that they are not the same, and
doesn't help internationalization.

>seriously helpful to the IDN working group reaching closure.

I think it might help quite a few people who don't really
like ACE to know that the (key) ACE proponents understand
that ACE is a layer violation in the (character) encoding
stack, and will have its serious negative consequences like
any other layer violation. At least it would help me.

Regards,    Martin.

---

From: "Adam M. Costello" <[email-masked]>
Date: Tue, 9 Oct 2001 22:28:57 +0000

Martin Duerst <[email-masked]> wrote:

> I think it might help quite a few people who don't really like ACE
> to know that the (key) ACE proponents understand that ACE is a layer
> violation in the (character) encoding stack, and will have its serious
> negative consequences like any other layer violation.

I usually think of a "layer violation" as a case of one layer being too
interdependent on the inner working of another layer, instead of knowing
only the interfaces to the layers immediately above and below it.

ACE merely inserts a new layer, but the layers can still be cleanly
separated.

If the old stack looks like this:

    arrangement of glyphs
    sequence of characters
    sequence of code points
    sequence of octets

then the new stack looks like this:

    arrangement of glyphs
    sequence of characters
    sequence of code points
    sequence of basic code points
    sequence of octets

The old transformations between glyphs and characters, and between
characters and code points, are unaffected.  The transformation between
basic code points and octets is exactly like the old transformation
between code points and octets (except that the repertoire is smaller,
so a more primitive serialization is likely to be used, typically
ASCII).  A new translation between code points and basic code points is
introduced, but it is orthogonal to the transformations at the other
layers.

AMC