Re: [idn] The report from the design team

["James Seng/Personal" <James@Seng.cc>]

Before this discussion goes further, please put your specific changes to
the requirements with the proposed new wordings here. Thanks!

-James Seng

----- Original Message -----
From: "Eric A. Hall" <ehall@ehsco.com>
Cc: <idn@ops.ietf.org>
Sent: Wednesday, February 14, 2001 3:26 PM
Subject: Re: [idn] The report from the design team


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