Re: [idn] The report from the design team

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

> the requirement might be overstated, but I don't think we can
> eliminate it completely.

Let me point out that this requirement prohibits the EDNS, DNSII, and new
Class proposals, and also prohibits longer labels and names (they will not
be forward compatible with legacy equipment). No change to DNS whatsoever
will be tolerated by the current requirement.

> to put the question in a more practical light: if someone sends
> out mail with a return address that uses an IDN, is it acceptable
> if the recipient cannot reply to that message unless his mail
> reader and the chain of SMTPs between him and the original sender
> support IDNs?

The end-user still has to upgrade the MUA to use ACE. If he doesn't, then
at least one of the SMTP servers will have to do the work (assuming they
accept an unconverted IDN from the MUA in the first place) whenever the
user clicks on the internationalized mailto: link.

We are talking about varying degrees of breakage. Anything that presents a
process with a local-format IDN has the potential to break things if the
systems aren't compliant with whatever solution is chosen, and this
includes ACE. Breakage of some degree is absolutely unavoidable.

As for how a new DNS message format would address this problem, no mail
server should accept MAIL FROM which includes a domain name that the MTA
doesn't recognize as legitimate, so in all likelihood a new ESMTP
extension would almost certainly be required in order to accomodate an IDN
solution that uses longer labels/names or non-ascii characters in the SMTP
envelope. This may be required even when ACE is used though. What then?

There are other examples which are also hard to deal with. Ancient print
servers that fire off alerts over SMTP aren't likely to be fixed easily,
and ACE allows them to work with IDNs after a manual conversion and
reconfiguration, while this would not be possible with a new DNS message
format. There are at least a dozen operational solutions to that kind of
problem however, even when a protocol solution is not available.

Tough question. I don't know the answer. It just seems to be a bad idea to
preclude all options up front.

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