Subject: [idn] We are quibbling about WHAT?

From: Dave Crocker <[email-masked]>
Date: Sun, 29 Jul 2001 17:31:05 -0500

UTF-8 takes a set of table entries, and maps them to 8-bit strings.

ACE takes the same set of table entries and maps them to a subset of 7-bit 
ASCII.  For order-of-magnitude convenience, let us call this 6.5-bit ASCII.

Never having been any good at math, I'm still going to suggest that the 
entire debate that has garnered such religious positions -- and, far worse, 
is causing continuing delay to this working group -- concerns an encoding 
efficiency difference of, at most, 19 percent.

For strings that are less than 100 characters long!

Unless someone can refute the transition impact discussion in my "iDN 
Transition Support Requirements" note, is it not time to choose an ACE and 
move on?

d/

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

---

From: "Soobok Lee" <[email-masked]>
Date: Mon, 30 Jul 2001 09:31:08 +0900

----- Original Message ----- 
From: "Dave Crocker" <[email-masked]>

> For strings that are less than 100 characters long!

some ACE proposals produce about 40% shorter ACE labels  even for
 10 characters long  han/hangeul native labels, compared to that of DUDE.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Sun, 29 Jul 2001 20:13:24 -0400

Hi Dave. How's Bolivia (or Peru)?

Not to quibble overly, but ...

There are 63 elements in the -0-9A-Za-z set, or 6 bits (minus one).

Worse, with case folding, there are 37 elements in the -0-9Aa-Zz set,
or 5 bits (plus 5).

The "6.5-bit ASCII" tag is ... generous. How about "sub-6-bit-SKI",
or "Modern Baudot" (Baudot used 5 bits, with the LTRS and FIGS chars
to switch between two 31 valued repetoires, of which 27 had unique
values). It is very much in the spirit of ACE.

UTF-8 does not take an 8859-1 string and transform it into what some
have referred to as "ASCII-gibberish". Repeat for -2, -3, ... -9.

That said, I don't think anyone working on an 8-bit proposal, which
means those in which the value of "A" is 0100 0001 (8859-1), rather
than x100 0001 (ASCII), where "x" indicates "don't care", and allows
for some multi-byte extension, e.g., UTF-8, picked an 8-bit clean
approach for length reasons. I also don't think anyone working on
any 7-bit proposal, favorably referred to as "ACE", and available
in more shapes, colors and sizes than shoes, picked an 8-bit dirty
approach for length reasons.

I think the encapsulate vs extend debate is about architecture. It
just happens that 63 bytes does focus some attention on effective
characters per mechanism, and encapsulation schemes using only 5 bits
plus a nickle per octet are at a disadvantage over extension schemes
that use at least 7 bits per octet.

Most of the ACE variation numbers are concerned with CJK character
repetoires, I don't recall seeing any for 8859-* repetoires. This
may be selective memory on my part, but if it isn't, this is a topic
worth visiting.

The transition impact discussion can't be refuted. It was the subject
of RFC 801, and others. I'm particularly fond of lines 51 - 64 of
that transition plan by the way.

Time to choose an ACE and move on? I'll pass thanks. A half-dozen
browser-hack marketeers, a trio of monopolies, and the DNSO food
fight, is inadequate motivation to solve a complex problem. A good
solution is, and differences in that are why we are where we are.

Bifurcation of the WG is a possibility, it has its merits. So too
has closure. Or, the co-chairs can find "rough consensus" and try
and get working code creditable.

Eric
P.S. I'd like a reproduction Quipu, please.
Eric

---

From: David Hopwood <[email-masked]>
Date: Mon, 30 Jul 2001 16:55:30 +0100

-----BEGIN PGP SIGNED MESSAGE-----

> efficiency difference of, at most, 19 percent.

The debate between ACE and UTF-8 has nothing to do with encoding
efficiency. The benefit of UTF-8 is in having DNS names in the same
encoding as the surrounding text, rather than having to treat them as a
special case.

- -- 
David Hopwood <[email-masked]>

Home page & PGP public key: http://www.users.zetnet.co.uk/hopwood/
RSA 2048-bit; fingerprint 71 8E A6 23 0E D3 4C E5  0F 69 8C D4 FA 66 15 01
Nothing in this message is intended to be legally binding. If I revoke a
public key but refuse to specify why, it is because the private key has been
seized under the Regulation of Investigatory Powers Act; see www.fipr.org/rip