Re: [idn] Debunking the ACE myth

["Eric A. Hall" <ehall@ehsco.com>]

> > > In the IDNA proposal we have specified that an application which
> > > handle IDNA (like you seem to say that the browser is) only
> > > support IDNA if also the content of the clipboard is converted
> > > to ACE before the domainname is passed to other applications
> > > (which doesn't handle IDNA/ACE solution).
> >
> >In that case IDNA is impossible. It is impossible for a browser to
> >know what text in a web page is a host name.
> 
> Not true. ACE names are quite easy to pick out of document content:
> they have the name prefixes.

This assumes that it wasn't written and stored in transliterated form. I
would think that the native format will be the most common for
user-written material (especially email bodies), not ACE. This goes
against the original argument. Requiring these products to encode email
addresses as ACE will be difficult, if not impossible. Every string that
looked like an email address which really wasn't an email address (this
goes into the realm of document contents; passwords can have ldh@ldh.ldh
syntax, for example) would be broken by the converter.

For HTML with links, URLs will require ACE for some time, so the argument
is more valid there (at least until HTML makes the URL guessing invalid).
But for things like HTML lists of POP3 servers which do not have common or
widely-used URLs, it once again becomes difficult for an agent to
automatically convert native-format hostnames into ACE.

I really don't think a mandatory look-alike conversion will work. The
strongest emphasis I would put on it would be MAY, with a strong caveat.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/