Re: [idn] WG last call summary

[Dave Crocker <dhc@dcrocker.net>]

At 11:45 AM 3/16/2002 -0600, Eric A. Hall wrote:
> > UTF-8 is an encoding.  IDNA uses an encoding.  Neither is a "native"
> > representation of the semantics.
>
>If all of the inputs and outputs are using UTF-8, then UTF-8 on-the-wire
>is about as close as you can get to a direct representation.

If one plus one were three, the result would be odd.

Non-sequitors are not overly helpful to technical discussions, Eric.


At 12:09 AM 3/17/2002 +0000, D. J. Bernstein wrote:
>There's no theoretical obstacle to making multiple character encodings
>work

Nice to see you admit that.


>Massive redeployment of, at a minimum, every web browser in the world.

Oh, rather more packages than that need changing.

However it's nice to note that for any of them to enter the world of 
enhanced DNS characters, they would need changing anyhow.

So IDNA does not affect this statistic, other than not making it worse.  By 
contrast, a UTF-8 based encoding will be expected to break most of the DNS 
clients that have not changed.  This is a very poor transition strategy.


>And that's just for domain names! Is every worldwide identifier---for
>example, mailbox names---supposed to have its own massive upgrade?

Yes, Dan.  Dealing with an installed base is really a hassle.  However it 
beats the alternative of not dealing with that base.


>UTF-8 offers a way out of this mess.

Well, no.  In fact, it creates a much, much more serious transition 
requirement.  It requires a full-system switchover, rather than permitting 
incremental adoption.


At 12:52 AM 3/17/2002 +0000, D. J. Bernstein wrote:
>Internationalized domain names are a failure if non-ASCII glyphs don't
>appear on the screen. Have you completely lost sight of the goal here?

Transition plans that require everyone to switch over all at once ensure 
that failure, or have YOU lost sight of the goal here, Dan?

The issue is how to accomodate the installed base.  IDNA permits 
incremental adoption.  Anyone who opts in gets benefit.  However no one is 
required to opt in and those who do not opt in are not penalized with 
anything worse than ugly strings.

 From the standpoint of transition schemes for an installed base, this 
represents the ideal.


>The interoperability problems begin when IDNA gobbledygook is converted
>to the local character encoding for display. If the result is copied to
>another program---through pipes, copy-and-paste, whatever---then that
>program's lookups will fail.

Dan, you need to talk to the people responsible for inter-process 
communications within a single system.  That ain't the IETF.

d/

----------
Dave Crocker <mailto:dave@tribalwise.com>
TribalWise, Inc. <http://www.tribalwise.com>
tel +1.408.246.8253; fax +1.408.850.1850