[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [idn] San Diego Meeting Notes
- To: idn@ops.ietf.org
- Subject: Re: [idn] San Diego Meeting Notes
- From: Paul Hoffman / IMC <phoffman@imc.org>
- Date: Tue, 23 Jan 2001 17:39:04 -0800
- Delivery-date: Tue, 23 Jan 2001 17:41:20 -0800
- Envelope-to: idn-data@psg.com
At 11:32 PM +0000 1/23/01, D. J. Bernstein wrote:
>I object to ACE because the initial switch involves massive unnecessary
>costs. The costs are discussed in http://cr.yp.to/proto/idn.html. See
>below for a transliterated copy of idn.html.
That document appears to detail the costs (but does not quantify
"massive") for upgrading applications to any form of IDN. It does not
differentiate the costs between upgrading to an ACE or to UTF8. It
does not say why going to an ACE is "unnecessary".
The fact that some programs can today display UTF-8 but cannot check
nameprepped UTF8 shows that all programs are going to need to be
updated for input of DNS names. If you believe that the cost of going
to ACE is massive but going to UTF8 is not, that implies that the
UTF8-to-ACE conversion cost is massively larger than the cost of
doing nameprep. It is likely that the opposite is true: writing the
normalization step in nameprep is probably much, much harder than
coding an ACE, particularly LACE.
>I also object to the idea of specifying a short-term plan without a
>long-term plan. How can we rationally evaluate the costs of ACE if we
>don't also evaluate the likely costs of a future ACE-to-UTF-8 switch?
Wouldn't those costs be constant regardless of what the long-term
plan is? Put another way, which two of the long-term plans proposed
have different ACE-to-long-term costs?
>I also object to the characterization of ACE as an ``application-only''
>solution.
Good point. It might have more carefully worded as the design team
did: it is for the presentation layer of applications.
> Is an MTA an ``application''? How about a DNS server?
If it has a presentation layer, it will be affected by IDNA; if not, no.
>As for nameprep: When are we going to see some working software?
Many months ago.
> I have
>a bunch of examples that I'd like to try; it's difficult to evaluate
>nameprep without software.
Some testbeds have already been announced on this list. Mine (which
is written in Perl and the source code is available) is at
<http://www.imc.org/nameprep/>. Please feel free to use the web form
or, better yet, grab the source and run it locally. By all means
report any bugs you find to me (you don't need to send them to the
whole mailing list). Open source implemenatations in C or C++ would
probably be more appreciated by the folks on this list than my
non-optimized Perl hack^H^H^H^Hscript.
--Paul Hoffman, Director
--Internet Mail Consortium