Re: [idn] WG last call summary

[Harald Tveit Alvestrand <harald@alvestrand.no>]

--On 15. mars 2002 20:56 +0000 "D. J. Bernstein" <djb@cr.yp.to> wrote:

> Under the IDNA deployment plan, names in the IDNA character encoding
> will start showing up in subscription lists immediately. Those names
> will be displayed as gobbledygook. The ezmlm-list author will be forced
> to have ezmlm-list convert addresses to the local character encoding.
>
> However, if ezmlm-list converts from the IDNA character encoding to the
> local character encoding, then the script shown above will break. Mail
> will bounce. That's an interoperability disaster.

under the scenario dan presents:

1) upgrading the qmail-inject program to support encoding will do no harm. 
Anything that will be changed by encoding was an illegal email address 
under the old rules.

2) upgrading both ezmlm-list and qmail-inject does no harm in the scenario 
given.

thus, I think the defensive behaviour for ezmlm-list is to implement a 
switch:

ezmlm-list 
--yes-I-have-really-upgraded-the-thing-that-will-read-this-to-understand-em
ail-addresses-with-utf-8-characters-in-them

given that in the endgame of essentially all programs being upgraded to 
undestand UTF-8 email addresses, this switch will be a bother, it should 
probably be capable of being specified in a configuration file, so that it 
can be left on and negated when needed.

3) contrary to some beliefs, watching gobbledygook is not known to cause 
permanent damage in human beings. So not upgrading anything does not cause 
much harm either.

4) yes, I do agree that specifying this level of behaviour is out of scope 
for the IETF.

                 Harald