Subject: Re: [idn] time to move

From: Dan <[email-masked]>
Date: Wed, 23 May 2001 11:44:07 +0200 (MEST)

>>1) Are we going to use UTF-8 only? (and accept that this will force
>>    many applications to get fixed, that otherwise could wait a long time
>>    with fixing).
>
>this was not the design team recommendation and perceived wg concensus.

That was long time ago. There have been much talking about UTF-8 since then.
But I agree that most do not dare say "just UTF-8" so I expect
a solution with both UTF-8 and ACE is what most think is best.
 
>This electronic straw poll is to find if the wg still think the 
>idna-nameprep-ace is the way to go. If we find no concensus on 
>idna-nameprep-ace proposal, then we go back to the drawing board.

I do not think it answers that, because it does not specify the
alternatives.

I also dislike combining two things into one. Nameprep has some basic
failures in which characters match which that should be agreed on first.
Before it can go on.

>>2) If the answer to 1) is No, the an ACE will be nedded.
>>
>>    The we get: Is the goal to have UTF-8 as nativ format in DNS in
>>    the future, or are we going to use ACE forever?
>>      - If we are going for UTF-8 then ACE is a transition mechanism.
>>        The ACE should then be simple and fast to implement.
>>      - If we are going for ACE forever, the ACE selected need to
>>        be compact so that as many characters can be included in
>>        as few bytes as possible.
>
>the ACE design team is working on that. If there is a concensus of the wg 
>for idna-nameprep-ace, then the ACE design team will hopefully come to the 
>wg with a recommendation.

Why is the ACE design team working on that? It is something that
should be discussed by all before we decide what ACE should be used.
Where is the archive of the ACE design team work?

If we decide that DNS should use UTF-8 and ACE is a transition
mechanism, IDNA is only a temporary and partial solution to what we
need. ACE support should be declared dead about 2010 so only UTF-8
is supported.

I do not want ACE for more than a transition mechanism with a
clear end date. I am tired of "quoted-printable" solutions and all
the problems they result in.
Also why only IDNA? Why not like in UDNS with server support.
Support at my site will be server based, as far as possible. It
is much easier than upgrading all applications.

   Dan

---

From: "James Seng/Personal" <[email-masked]>
Date: Wed, 23 May 2001 18:08:40 +0800

> Where is the archive of the ACE design team work?

I think the right phrasing is that the ACE design team is working on a
ACE recommendation for the WG. The WG still have to decide if it is
willing to go with the recommended solution.

As I recalled during discussion with the design team, the archives would
be make public after the design team finish their work.

-James Seng

---

From: [email-masked] (J. William Semich)
Date: Wed, 23 May 2001 07:32:46 -0400

I agree with Dan. Let's focus on a clear point of agreement, and ask for
consensus on *just* nameprep. 

So, for the record, I answer "no" to the straw poll, and propose a
more-limited poll on agreeing to move forward with nameprep.

I'd prefer to reconsider other alternatives, whether transition based or
not, such as UDNS, Paul and Marc's IDNE and John's proposal for a new class
(draft-klensin-dnsclass0e) instead of a permanent ACE solution like IDNA at
this point...

Regards,

Bill Semich

>is much easier than upgrading all applications.
Bill Semich
President and Founder
WorldNames, Inc.
http://www.worldnames.net
[email-masked]

---

From: [email-masked] (J. William Semich)
Date: Wed, 23 May 2001 07:33:39 -0400

Regards,

Bill Semich

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 23 May 2001 20:37:00 +0000

Dan <[email-masked]> wrote:

> mechanism...

Please remember that DNS is not the problem.  DNS is just one of many
protocols that embed domain names.  Others include message headers,
SMTP, URIs, ssh keys, PGP keys, and on and on.  All these protocols, and
the software that implements them, will need to be revised if domain
names are allowed to contain non-LDH characters.

Also note that if ACE is a transition to UTF-8, then there are really
two transitions: one from LDH-only to ACE, and another from ACE
to UTF-8.  If ACE is seen as the solution, then there is only one
transition.

Finally, note that UTF-8 has issues with encoding efficiency (the length
of the encoded string).  It's excellent for Latin scripts, good for CJK
scripts, bad for some other popular scripts like Cyrillic and Arabic,
and horrible for most Indian and southeast Asian scripts.  UTF-16 is
excellent for CJK and bad for everything else.  An ACE can be designed
to be more balanced, achieving good or at least decent efficiency for
all scripts.

AMC

---

From: Roozbeh Pournader <[email-masked]>
Date: Thu, 24 May 2001 02:03:25 +0430 (IRDT)

On Wed, 23 May 2001, Adam M. Costello wrote:

> Finally, note that UTF-8 has issues with encoding efficiency (the
> length of the encoded string).  It's [...] bad for some other popular
> scripts like Cyrillic and Arabic, [...]

Would you describe why do you see UTF-8 bad for Arabic and Cyrillic? You
don't want to suggest usin 8-bit character sets, do you?

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 23 May 2001 21:52:56 +0000

Roozbeh Pournader <[email-masked]> wrote:

> Would you describe why do you see UTF-8 bad for Arabic and Cyrillic?

Because for those scripts the ACE encoding is usually significantly
smaller than the UTF-8 encoding.

Seen another way, the Cyrillic and Arabic alphabets are about the same
size as the Latin alphabet, so the amount of information per character
is about the same for all three scripts, but UTF-8 uses almost double
the number of octets per character for Cyrillic and Arabic as opposed to
Latin.

AMC

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 23 May 2001 18:02:05 -0400

Adam,

> protocols that embed domain names.  Others include message headers,

How does dns embed domain names? Is the resolution question (assuming it
still exists) equivalent to the transparent to code-set-dependent apps
question?

I'd the impression it wasn't, and that most of this group's focus was on
constraints for, or elimination of, the transparency question.

I fail to see the point of your second note.

The issue of encoding efficiency is interesting. A small cabal (the IE6
P3P implementors, myself and some of the P3P Spec WG considered just how
"compact" to make XML privacy policies on cookies. Two other groups, the
Mozillia and Amaya developers, and quite a few IETF I-Ds hopefully set on
a standards track trajectory, seem genuinely committed to XML. If your
view is the best one, then most of these people, and their products in the
56k-bandwidth-defined mass market are very poorly advised.

As today is "call me an idiot" day, would you do me the kindness of letting
me know where the i18n architectures of AIX 3.2, Solaris 2.6, and HP-UX 10
and their successors in interests, all of which use, or anticipated use of
utf8 for internal encoding. I've a lasting interest in the strengths, and
weaknesses, of "code set independent architecture" conception, implementation
and deployment in mid-90's POSIX operating systems.

I've obviously failed to grasp something deep and profound, either about
l10n-capable edge devices (other than cell phones), or last-mile network
characteristics, and so I've probably made a muddle of the dns registry
provisioning protocol, which a) uses XML, b) allows for utf8 in the
encoding of technical and social data, c) declines to impose heroic hardware
on its nodes, and d) also declines to impose heroic bandwidth on its links.

Tia,
Eric

---

From: "Adam M. Costello" <[email-masked]>
Date: Wed, 23 May 2001 22:53:31 +0000

Eric Brunner-Williams in Portland Maine <[email-masked]> wrote:

> > Please remember that DNS is not the problem.  DNS is just one of
> > many protocols that embed domain names.  Others include message
> > headers,
>
> How does dns embed domain names?

Domain names appear in message headers, SMTP commands, URIs, ssh keys,
SSL certificates, and DNS requests and responses.  All I meant was that
DNS is just one of many protocols that exchange messages containing
domain names.  And virtually all such protocols (except DNS, actually)
assume that domain names contain only LDH characters and dots.  What
happens in these protocols if domain names contain other characters?  I
think most of the protocol specifications either don't say (in which
case implementations might do anything) or they say it's an error.

> Is the resolution question (assuming it still exists) equivalent to
> the transparent to code-set-dependent apps question?

I'm not exactly sure what you mean by either one, but they sound
different.  Resolving IDNs is going to be pretty easy no matter what
we do, because DNS is pretty versatile.  ACE makes resolution trivial,
but I do *not* see that as an important argument in favor of ACE.  The
argument for ACE is that it allows IDNs to flow through all the untold
existing protocols and software unharmed.

> I fail to see the point of your second note.

Which was:

    Also note that if ACE is a transition to UTF-8, then there are
    really two transitions: one from LDH-only to ACE, and another from
    ACE to UTF-8.  If ACE is seen as the solution, then there is only
    one transition.

Is the point not obvious?  Transitions are typically difficult and
disruptive.  Two transitions are twice as difficult and disruptive as
one.

> The issue of encoding efficiency is interesting.
> [long defense of UTF-8, XML, and inefficient encodings in general]

I did not mean to imply that UTF-8 is bad in general, or that encoding
efficiency is important in general.  UTF-8 has many amazingly wonderful
properties: all ASCII strings are UTF-8 strings, substrings cannot be
misinterpreted, lexicographic sorting of code points is preserved, and
no look-ahead is required for decoding.  I am very impressed by the
elegance of UTF-8, and would endorse it for almost any situation where
you want to use a single character encoding.

Encoding efficiency is usually not a top concern.  Bandwith grows, disks
grow.  Making things easy and versatile is usually more important than
saving bits.

But in this case, we have a hard limit of 63 bytes per label.  That's
why encoding efficiency matters in this case.

Although I suppose, if you already expect to update every protocol and
every piece of software that uses domain names, you might as well remove
the 63-byte limit.  In that case, I would have no problem with UTF-8.
But I'm extremely skeptical of that whole approach.

AMC

---

From: Martin Duerst <[email-masked]>
Date: Thu, 24 May 2001 08:27:03 +0900

>the 63-byte limit.  In that case, I would have no problem with UTF-8.

How many 'real' domain names are longer than 20 characters?
By 'real' I mean those not made artificially to meet the limit,
or otherwise more looking like a joke than anything else.
And how many of these could be shortened with a bit of
ingenuity if needed? And how many of these could be dealt
with by splitting them into two labels?

I see the 63-byte limit as something we have to ask ourselves
carefully about, but not at all as a show-stopper for UTF-8.

Regards,   Martin.

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 23 May 2001 22:18:57 -0400

...
> domain names

In a fairly peculiar and constrained way. Unique one might say.

(dns) resolution != (apps) transparency. Good, or at last that is
comfortably consistent with my own ignorance and sloth.

I still fail the novel point of your second note, and I'm still
surprised that ACE could be considered as anything other than a
"temporary", and controversial fix, unless the problem scope has
changed without my being aware of it.

> [long defense of UTF-8, XML, and inefficient encodings in general]

Thanks for the send-up, but a whole bunch of people are betting their
time and money that there are other "efficiencies" than octet counting.
Thus far, the router, host, link, and even last-mile vendors haven't
stopped them with stakes, nooses, or other bits of constructive criticism,
and argued forcefully for "efficiency".

If the label-space is the issue referred to by "inefficiency", then
as a label-space vendor I'm really interested.

	I've blocked or otherwise squashed labels shorter than two
	octets, and have an idea as to how many "TLA" labels I will
	sell before year's end, and have a poorer idea as to how
	many labels I will sell over five years that are 20 ASCII
	characters or less, or at 30 alphanumerics plus diacriticals.

	I haven't a damn clue what the demand is for labels twice
	that size in the ASCII or ISO8859-* markets, or how important
	labels this size are in the CJKV market -- except that CNNIC
	already went utf8.

	True, the CNNIC presentation and oral comments at -50 did cite
	label octet limits as inconvenient when the encoding is utf8,
	but they obviously made a choice -- an engineering trade-off,
	and rolled out a utf8 architecture.

That's just our market research, and CNNIC's deployment experience. Your
mailage may vary, and you can see Martin's comment as well.

Cheers,
Eric

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 May 2001 22:54:51 -0400

> changed without my being aware of it.

it is less controversial because it is easier than the alternatives.

it is perhaps also worthwhile to point out that fixes based on 
EDNS will not work so well through intermediaries.  so if we want
a utf-8 query protcol in addition to the ACE query protocol
that we need for compatibility with existing applications, then
we might have to wait a while before it can actually be used.

for me the choice is clear: ACE is necessary in the short term.
a utf-8 query protocol might be desirable in the longer term,
especially for new protocols that don't have the burden of 
backward compatibility.  but we have the luxury of defining 
the utf-8 query protocol after we get the ACE solution out the door.  

we cannot make the jump directly to utf-8 - it is simply not practical.

Keith

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 23 May 2001 23:03:16 -0400

> we cannot make the jump directly to utf-8 - it is simply not practical.

Does "we" include CNNIC?

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 May 2001 23:11:00 -0400

> Does "we" include CNNIC?

it means "we" the Internet.  various islands can go to utf-8 if they
don't care about backward compatibility.  but the purpose of a standard
is to provide a solution that everybody can use.  we don't need to provide
a solution that can only be used by an island - others are already
doing that quite well.

---

From: Martin Duerst <[email-masked]>
Date: Thu, 24 May 2001 12:32:11 +0900

Hello Keith,

Your conclusion

>we cannot make the jump directly to utf-8 - it is simply not practical.

isn't really a given. The main point in support of UTF-8 is that
the main drive for idns is coming from Web usage (http URIs).
Email is a very clear second, and all other usages don't have
1% of the pressure and urgency we have for Web usage. If we can
solve the problem for the Web and for Email, we get some time
to work on the rest. Even if we have a solution that in the
near term only works on the Web, that gives us quite some time.

This correlates extremely well with the fact that the average
Web browser is about the easiest place to introduce UTF-8 idns
(or any other idn solution, for that matter), and that the main
protocol there (HTTP) also should work nicely. Overall, it may
take ten years, but the things people want most will work much
sooner. Also, we are moving towards the final solution directly.

Also, I don't buy that once an ACE is deployed, we will come back
to work on UTF-8. Also, I don't buy that application protocols
will do the work to upgrade to UTF-8 internally if they can just
use ACE. Some might, but most won't. And the result would look
strangely backwards. On the other hand, if any particular
application (e.g. email) really thinks they need ACE, they
can do that on their own, and bear the consequences.

Also, if one puts together the protocol issues, the user interface
issues, and the management issues (zone files, scripts, and the like),
rather than just looking at the protocol issues, ACE is about as
impractical as anything else.

Regards,   Martin.

---

From: Keith Moore <[email-masked]>
Date: Wed, 23 May 2001 23:49:06 -0400

> the main drive for idns is coming from Web usage (http URIs).

the 'main drive' for IDNS is irrelevant.  the major applications do not
exist in isolation; web and email together touch almost everything else.
we can't solve the IDN problem for just the  two and pretend that it will
not do harm to other applications; the boundaries are not that clean.

> to work on UTF-8. 

I didn't say that we would.  I said that we "might".  But I suspect
that it's at least worthwhile to consider as a followon effort, and I
also suspect that there are enough people who  are willing to do the 
work.  Whether application developers will use it is a different
matter.  But it's hard to see why they wouldn't use it if their protocols
are using UTF-8 internally anyway.

> Also, I don't buy that application protocols
> strangely backwards. 

I didn't say that they would do the work to upgrade to UTF-8, and it's
not even clear that it's desirable overall for them to do so.  I don't 
think this is backwards at all - it is just the way of things.  Old 
interfaces that work tend to get used with few changes for a very long time.  
The POTS telephone interface is ancient and very clunky, and we could
do far better today.  but almost all subscriber equipment still uses it.

> On the other hand, if any particular

no they can't, because unless DNS supports queries by ACE from day one,
those applications will not work with ACE names. 

> impractical as anything else.

all of the above issues exist with each of the solution paths.
ACE wins because it has the best backward compabtibility and the
lowest barrier to quick deployment.

Keith

---

From: "Adam M. Costello" <[email-masked]>
Date: Thu, 24 May 2001 03:45:13 +0000

Eric Brunner-Williams in Portland Maine <[email-masked]> wrote:

> I'm still surprised that ACE could be considered as anything other
> than a "temporary", and controversial fix

Well, sometimes good ideas are surprising. :)  I admit that when I first
heard about ACE, it struck me as an ugly hack.  But once I realized what
an interoperability nightmare it would be to have domain names with
no LDH representation, my opinion changed.

New and updated protocols are free to support UTF-8 if they wish, but
the ACE representation will need to continue to work for a long time,
because domain names can pass through old protocols and old software
along the way.  What compelling reason is there to set a deadline beyond
which ACEs will stop working?

> stopped them with stakes, nooses, or other bits of constructive
> criticism, and argued forcefully for "efficiency".

I don't think there is any shortage of bytes on links or in routers.
It's only in domain name labels where there's a limited supply.

> True, the CNNIC presentation and oral comments at -50 did cite label
> octet limits as inconvenient when the encoding is utf8, but they
> obviously made a choice -- an engineering trade-off, and rolled out a
> utf8 architecture.

UTF-8 is not bad for Chinese.  21 Chinese characters is plenty of room,
because there's a lot of information per character (most words are two
characters).  But UTF-8 would impose the same 21-character limit on most
Indian and southeast Asian scripts, and those characters are comparable
to Latin letters in terms of information content--it takes several of
them to make a word or a name.

The greatest thing about UTF-8 is its compatibility with ASCII.  But in
the case of IDN, if you care about compatibility, you need ACE.  If you
don't care about compatibility, and you segregate the IDNs from the LDH
domain names, then UTF-16 is probably better than UTF-8, because then
everyone would get 31 characters per label, which even I would concede
ought to be enough.  I wonder why CNNIC didn't go with UTF-16.  Maybe
they don't plan to segregate the IDNs from the LDH domain names, and
are counting on software that uses UTF-8 internally to "just work" by
accident.  Of course, some things will just break, too.

AMC

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Wed, 23 May 2001 23:58:42 -0400

Does "we" exclude anyone?

For quite a long time "we" ment .arpa, as in [email-masked].

> various islands can go to utf-8 if they don't care about backward
> compatibility

I don't have a whole lot of 3Mb/sec Type I Ethernet lying about these
days (see above). I also don't have XNS forcing me to maintain bridged
subnets, and generally don't have pervasive obsolecense controlling my
site's infrastructure. What I do have that is obnoxious is MS Exchange,
but that's another form of brain-death.

I'm leery of letting the phrase "backward compatibility" run the show,
as it may not care very much about anything but the (vain)glorious past.
Recall, in .ARPA-time, packets to the PRC was less likely than to RSRE.

> the purpose of a standard is to provide a solution that everybody can use

Hmm. I don't suppose anyone (other than Ken Lunde) has a clue how many times
an ASCII compatible extension has been adopted by sundry national standards
bodies (non-US, obviously, lack of necessity) which for some reason simply
haven't been "adopted by the internauters" ("us" in some locales).

The CJK series of standards is stricking in its optimism that if ASCII is
repeated sufficiently often, then its extension will be advanced (somehow).
From JIS C 6226-1978 to the present. It would be really funny if we were in
their shoes, trying to deal with some indifferent EBCDIC monster that made
sounds like "global transparancy" and "backward compatibility" every time
we tried to get it modernized. Oh. Been there. Done that. Got the tee-shirt.

> we don't need to provide a solution that can only be used by an island

Isn't this slightly disengenious?

Isn't the line of march of uniqueness and consistency and so forth predicated
upon the inexistence of ... "island(s)", and the non-deployment of utf8?

I think I'd like a helping of ECE please (EBCDIC COMPATIBLE EXTENION, shouted
naturally), and some variable length bytes on the side.

Eric

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 May 2001 00:16:33 -0400

> days (see above). 

perhaps not.  but the folks I know where were using IP over 3Mb/sec
Ethernet are still using IP.  IPv4 is starting to look obsolete due
to a shortage of addresses, but I don't know anyone who thinks it's
going to be discarded anytime soon.

> upon the inexistence of ... "island(s)", and the non-deployment of utf8?

it's predicated on the non-deployment of utf-8 *in Internet applications*
*at the time the IDN solution is deployed*.  it is currently the case
that few Internet applications support utf-8, and this isn't likely to 
change in the near future.

if you want to wait until everything else  is using utf-8 before deploying
IDNs that use utf-8, feel free.  I suspect that most of us don't want
to wait that long.  I also suspect that the fastest way to get to having
applications use utf-8 natively (if that's even worth the trouble)
is to use ACE IDNs in the near term.

Keith

---

From: [email-masked] (deng)
Date: Thu, 24 May 2001 12:12:04 +0800

Eric:

We are talk about technological solutions and problems. We should allow
any opinions. ANY USERs have the right to ask for using his language 
and his script. 

ANY ATTACKs are nonsensical,it have no help to solve problem.
......

CNNIC are friendly to anyone. 

What we should do is:
Keep quiet and think what's the best solution.

Deng Xiang
CNNIC CDNGROUP
2001.5.24

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 24 May 2001 07:09:55 -0400

Keith,

> to wait that long.

Of course I want to wait until <arbitrary precondition> before extending
the label space from 0x2d, 0x30-0x39, 0x41-0x5a, 0x61-0x7z to that set
plux (to be minimal and true to my calling) 0x2b. I'm a straw-person, and
its a given that everyone has vastly more clue than I.

Less rhetoric, more engineering. Please. Or we should stop meeting after
midight, list-time.

At present, no user of a dns may use code points other than the HDL list,
because <arbitrary precondition> is controlling until <arbitrary date>.

Getting a fix on <arbitrary precondition> and <arbitrary date> are worth
spending some time on, but aren't in themselves adequate for failing to
extend the existing set of label space octet encodings.

Well, BiDi just landed in the Mozilla tree. I'm willing to keep my own
personal shell at adb (a very old SRI prank), but there's an entire
cohort of users who's internet is post-modern, either because they data
just got "there" or because MicroSquash has eaten all the alternatives
they are capable of using. 

I suppose I could fix something. I hear that NSI has everything a grown
person could want in an IDN, if they were smart enough to let NSI define
need.

Eric

---

From: C C Magnus Gustavsson <[email-masked]>
Date: Thu, 24 May 2001 14:33:16 +0200 (MET DST)

On Wed, 23 May 2001, Adam M. Costello wrote:

> length of the encoded string).

Perhaps, but I don't think that is an issue for this working group.

We need fixed and unified codings for characters. That is among the
most important issues here, in any IETF work and in computer industry.
We need something which like ASCII is the same everywhere and doesn't
depend on what kind of computer or what protocol you're using.

The major reason for using Unicode/ISO 10646 is to know that 01101001
is always 'i', not only for 'i' but for all other characters as well.
I don't think some of the people here realize what kind of problems
the use of a myriad encodings result in.

But sure, in the case of protocols the problem is a little different.
We can let our computers do the conversions automatically. In theory.
Experience, however, shows that it is too complex for most software to
handle properly. The result is frequent leakage of internal formats as
e g in the case of quoted-printable.

That is why the IETF should specify a single encoding to be used in
all protocols. And - fortunately - IETF already has. BCP 18 (RFC 2277)
clearly specifies that UTF-8 is to be used as the standard character
set in all protocols. It might be argued that UTF-8 was a bad choice,
but this WG is not the place to change it. And until it is changed,
UTF-8 should be at least the long term goal for this WG.

/Magnus

And, btw:

I think "international characters" and "internationalized host names"
are very strange terms to use. What is more international than ASCII?
Wouldn't "local" and "localized" be better?

---

From: Martin Duerst <[email-masked]>
Date: Thu, 24 May 2001 22:36:05 +0900

>going to be discarded anytime soon.

Yes. But if that example applies to anything, it applies with
IP4 <=> ACE, IP6 <=> UTF-8, i.e. once we have ACE, we will have
big problems to get to UTF-8.

>*at the time the IDN solution is deployed*.

utf-8 is well supported by the recent generations of browsers.
The situation is similar for e-mail, with some exceptions.
Speaking about 'non-deployment of utf-8 in Internet applications'
is just spreading bad rumors. If a bit more people had had the
guts to go for utf-8 a few months ago, we would already have quite
some things running, end-to-end.

>it is currently the case

Can you please help me understand your facts by telling me how you
count?

>is to use ACE IDNs in the near term.

I think this is very seriously wrong. For a very large number of applications,
the only thing you have to do to work with utf-8 is make sure they are
8-bit compatible. In many cases, that's already the case. Even for something
as old as sendmail, an easy hack to achieve this has been described on this 
list.

Regards,   Martin.

---

From: "Bruce Thomson" <[email-masked]>
Date: Fri, 25 May 2001 10:44:16 +0900

> some things running, end-to-end.
Can somebody point me to a list of what e-mail clients are currently
working with UTF-8? I had been working under the assumption that
only browsers were working.

If these two apps are really there, I am surprised that we aren't just
going for UTF-8. History will likely record that it was this WG that
was the biggest barrier to deployment. ACE has outlived its usefulness
already.

Yes, I know that some things will break. Many multilingual apps are
broken in any case, but are being gradually fixed. Each new OS
or new piece of hardware breaks lots of things, but the world goes on.

---

From: Keith Moore <[email-masked]>
Date: Thu, 24 May 2001 23:17:04 -0400

> big problems to get to UTF-8.

Actually, we will have big problems to "get to" UTF-8 whether we
go to ACE first or not.    I'd argue that it's easier to "get to"
UTF-8 by going to ACE first because going to ACE allows folks to
get benefit without having to upgrade every single component
in the signal path. 

Of course, the goal of IDN isn't to "get to" utf-8 at all; it is 
to allow domain names to use characters outside of the ASCII repertoire.
If you want to "get to" utf-8 you're trying to solve a different
problem. If you insist that that problem be piggybacked on the
IDN problem then you're trying to make the IDN problem more difficult
than it needs to be.
 
> utf-8 is well supported by the recent generations of browsers.

Browsers are but a small subset of internet applications.

> The situation is similar for e-mail, with some exceptions.

Email support for utf-8 is essentially nonexistent.

> is just spreading bad rumors. 

You might not like it, but it's the truth.

> If a bit more people had had the

we would have some prototype code for each of the components.
that doesn't mean it would be deployable in the real world.

no application upgrade in the history of the internet has had 
signifcant deployment in a few months' time.  not even close.
even the MIME upgrade, which was far less disruptive than
what you are proposing, took many years.

we have prototype code for ACE solutions also.  ability to develop
a prototype isn't the issue here.

> Can you please help me understand your facts by telling me how you

I examine every internet application to which I have easy access - which is
to say, several dozen.  I see how many of them would work with UTF-8 domain
names.  The answer is zero.  Even the applications that accept UTF-8 input
don't do nameprep, neither do they  know better than to pass UTF-8 names 
to other applications that don't deal with UTF-8.  

the "just use UTF-8 in existing applications" approach has always been
a non-starter.
 
> as old as sendmail, an easy hack to achieve this has been described on this 

this analysis is simply incorrect, as numerous people have already pointed out.

this discussion can serve no further purpose.  I can't make you believe 
something that you don't want to believe, and I won't waste my energy trying.
but there is no basis for agreement between us, because your assessment of 
the situation is completely incompatible with mine.

Keith

---

From: Eric Brunner-Williams in Portland Maine <[email-masked]>
Date: Thu, 24 May 2001 23:40:03 -0400

Keith,

> problem.

Do you really think that Martin is proposing a different problem?

> If you insist that that problem be piggybacked on the

Do you really think that John's proposal fits this test poorer than the
proposal either you've ascribed to Martin, or Martin has actually made?

> this discussion can serve no further purpose.

So how about those NATs?

Eric

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 00:00:26 -0400

> Do you really think that Martin is proposing a different problem?

yes.  though he might not realize it.

> proposal either you've ascribed to Martin, or Martin has actually made?

I have trouble parsing this, so I might have misunderstood it.

But I think that both the problem that John appears to be trying to solve 
and the problem that Martin appears to be trying to solve are more 
difficult than the problem that the IDN WG is trying to solve.  

I think solving the IDN WG's problem is very worthwhile.  

I think solving Martin's problem is also very worthwhile, but I don't want 
to couple that solution to the IDN solution; I think doing so would 
delay the IDN solution too long, and as a result we would end up with a large 
variety of poor and non-interoperable solutions being deployed.

I'm not convinced that John's problem is solvable, but I think it's worth 
investigating.  But I don't want to couple this problem with the IDN problem either.

> > this discussion can serve no further purpose.

they're the handiwork of the devil, of course.   what else is new?

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 25 May 2001 00:09:54 -0400

> working with UTF-8? 

if by "working" you mean not only ability to display UTF-8 names but
also the ability to reliably look them up in DNS, send mail to them,
reply to them, and compare them with other UTF-8 names for equivalence,
the list of "working" clients is the empty set.

> I had been working under the assumption that

that's a misimpression.  browsers aren't working either, for any useful
meaning of the word "working".

Keith