Re: [idn] conversion collisions

["Adam M. Costello" <idn.amc+0@nicemice.net.RemoveThisWord>]

"Eric A. Hall" <ehall@ehsco.com> wrote:

> The default behavior as specified in IDNA is to perform conversion,
> even though these standardized protocols [whois and finger] do not
> require conversion, since they implicitly allow any charset.

Just because they allow any charset does not mean ToASCII is not
necessary.

If a non-ASCII domain name falls into the hands of an IDN-unaware
application, that application (or something else downstream of it) is
likely to choke on the name or fail to compare it correctly.

[For these particular examples, I think the output of finger and whois
are plain text intended for humans, not conforming to any standard
syntax, and thus not designed for applications to be able to pick out
the domain names from the surrounding text.  If that's true, IDNA does
not require the domain names to be in ASCII form, but rather recommends
that they be in non-ACE form.]

> if an IDNA mailer passes a converted i18n HTTPS URL to a web browser,
> then the comparison operation will fail.

How?  If the URI spec does not explicitly allow IDNs in the host field,
then whoever creates the URI is required by IDNA to convert the host to
ASCII before putting it in the URI.  That is the situation with today's
URI spec.

Now suppose there is a newURI spec that explicitly allows IDNs in the
host field, in some form other than ACE.  If the browser supports
newURIs, then it is IDN-aware, and hence it knows how to compare IDNs.
If the browser does not support newURIs, then the failure is the result
of passing a newURI to a browser that doesn't support newURIs, and you
can hardly blame IDNA for that.

AMC