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:[EMAIL PROTECTED]> TribalWise, Inc. <http://www.tribalwise.com> tel +1.408.246.8253; fax +1.408.850.1850
