Re: [idn] NSI Multilingual Testbed Information (fwd)

[James Seng <James@Seng.cc>]

"J. William Semich" wrote:
> I'm not making an "excuse against ACE" WRT the Pouflis patent. I was
> strongly informed by John Klensin in Pittsburgh that the issue of patent
> disclosure WRT potential IETF standards was *very* important to the IETF.
> This WG is proposing ACE as a potential standard.

Any discussion/presentation in IETF meeting, mailing lists etc by the
originator must be in compilence with RFC2026. In particular, John's
refers to your unwillingness to discuss your Copyright (or Patent) on
your slide during the meeting which is against RFC2026.

Once again, you bend someone words to suit your need. But this is not
the issue here so lets move on.

> However, I *will* make some technical observations about ACE now - since
> you suggest that is what I should do. I'm sure others will have differing
> opinions, though <smile>.

Great. Now we talking.

> 1. Usability problems: any domain part that has any non-ASCII character
> anywhere in it is
> transformed end to end to a form that is completely unreadable, causing
> problems at leakage points.

We are talking about wire-format. Human is not going to read it. Machine
is and I doubt they care if it is "ra--dskdsdfsljfdsd" or some other
gibberish.

> 2. The proposed ACE solutions are not ASCII-transparent at all.  In
> contrast, UTF-8 is completely
> ASCII-transparent.

I believe you refer to ASCII backward compatibility in UTF-8?

I understand the usefulness of this feature of UTF-8 in documents. All
ASCII text are automatically UTF-8 compilence. In fact, that is reason
for the design of UTF-8. 

Explain why is this is a technical merit in IDN context.

Before you answer..stop and think for a minute. *WHY* is it important
for IDN that a domain abcTAIWAN.com such that the "abc" remains as "abc"
in wire format? 

> 3. Significant new functionality must be added to every client that is to
> use an ACE IDN system.  Not so for UTF-8.

Not true. I would say it is the same with UTF-8. In fact, I would say it
is desirable that we *have* to modify the client (like the EDNS UTF-8
proposal) because this ensure only those clients which can handle UTF-8
will see UTF-8.

> 4. One ACE proposal says "With internationalized names, the user
> application MUST
> convert the pre-converted name into a post-converted name so that is
> acceptable to resolvers."  This is not the case with UTF-8.

I believe you refer to what commonly known as zero-level domain or ZLD
of introducing multilingual domain names.

That is not an ACE problem but really a deployment problem which can be
a problem for either UTF-8 or ACE. You didnt realise it because you are
using .NU to run your multilignual domain names. If you use a pure
multilingual domain names, you will understand it why.

(Pardon me. We are ahead of the current discussion here as this involves
deployment problems)

> 5. The ACE encoding schemes described in the ACE proposals are nearly
> always less
> efficient than the UTF-8 encoding scheme - often much less efficient
>  - even in those that utilize compression schemes.

Wrong, RACE actually encodes better than UTF-8 in some case.

Compression theory states that if you can compress some data, you going
to expand others data, i.e there is no compression algo which can
compress all data. But in RACE case, the compressed data occurs more
often than those it expand so it is okay, IMHO.

And RACE is still a moving target AFAIK. I been asking Paul to put some
other feature of UTR#6 into RACE which he has resisted. I am going to
keep trying. :-)

Anyhow, as I mention, I am not against UTF-8 solution, but not your
'just-send-utf8'. In fact, we (as in i-DNS.net) already started work
using UTF-8 on EDNS0 as proposed by Marc & Paul. Whether that is going
to be deployed is another issue.

-James Seng