[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/
