[idn] conversion collisions

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

[bringing this back on topic]

John C Klensin wrote:

> Of course, Whois or Finger might be better examples of your
> point, but those protocols did not specify the details of either
> the input or output formats.

That illustrates the problem exactly. The default behavior as specified in
IDNA is to perform conversion, even though these standardized protocols do
not require conversion, since they implicitly allow any charset. Ergo, any
conversion which is to be performed with those protocols must be specified
as part of an update to those protocols.

Another issue from another thread is X.509 certificates. The certificate
subjects must continue to use LDH domain names in order to interoperate
with legacy applications of legacy services. New protocols may choose to
specify the use of certificate subjects with Unicode characters, but
legacy services must use IDNA sequences in order for them to continue
functioning with legacy apps. However, if an IDNA mailer passes a
converted i18n HTTPS URL to a web browser, then the comparison operation
will fail.

In these cases (as well as with things like Message-ID) there will be
basic interoperability problems unless the governing specifications
clearly define specific behaviors. The only reasonable position for us is
to prohibit auto-conversion except where these decisions have been made.

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