Re: draft-klensin-emailaddr-i18n-00

This message responds to messages from both Dan Oscarsson and Simon
Josefsson.

Dan Oscarsson <[email protected]> wrote:

> IDNA do not support all international domain names due to being made
> to work using unaware DNS servers and clients.

What do you mean by "all international domain names"?  There was no
such thing as an "internationalized domain name" until the IETF defined
that term.  The definition appears in the IDNA spec.  Therefore, by
definition, IDNA supports "all internationalized domain names".  You
must have some other definition in mind.  What is it, and why is it a
problem that IDNA does not support that definition?

> As the IMAA draft stands today it will not handle all e-mail
> addresses.

Same question.  There is no such thing as an internationalized mail
address until we define it.

> Yes, both MUAs and MTAs need to be upgraded. But without that, the use
> of non-ASCII e-mail addresses will be so ugly that nobody will use
> them.  Just like MIME was not very popular before enough clients could
> handle it.

And UTF-8 headers will not be very popular before enough clients *and*
servers can handle it.  If speed of deployment is an issue, it looks
pretty clear to me that the "in applications" approach has the edge.

> I recommend that we go for full internationalisation of all headers so
> all headers are in UTF-8, and MIME-encoded headers are forbidden.

I have some ideas for how to do that, but I'm not sure that this is
the appropriate mailing list for that discussion (this mailing list is
about internationalized mail addresses, not headers in general).  If
someone starts a mailing list for discussion of UTF-8 headers, please
announce it here.  I still think there is no need for IMAA to wait for
any results from that discussion, and I think IMAA would still be needed
as a fallback even if a UTF-8 header solution existed.

> To make handling of UTF-8 text, the standard should require Unicode
> normalisation form C (NFC).

In any case, I think it would be good if receivers do not assume that
text is already normalized; they should perform normalization whenever
they want text to be normalized.  Then it will not be necessary for
senders to perform normalization.  The implementation cost is the
same whether the code is inside the senders or inside the receivers.
Forbidding unnormalized text on the wire doesn't do much except to make
troubleshooting more difficult for humans, who cannot see the difference
between normalized and unnormalized text.  It's not as if unnormalized
text is ambiguous.  It makes sense to forbid ambiguous constructions
like "user@foo@bar", but unnormalized text is not ambiguous--you
can determine exactly what was intended by normalizing it yourself.
Anal-retentive receivers that refuse to accept unnormalized text would
just frustrate users who telnet to port 25 for troubleshooting, if their
input method doesn't output normalized text.  Imagine how that would go:

> RCPT To: <user@host>
> 550 Unknown local part user in <user@host>

"Unknown local part?  But I can see it right there in the aliases
file..."  Later, after much hair-pulling:  "Oh, the supposedly
'internationalized' MTA is doing a brain-dead bytewise comparison, and
the representation produced by my input method is slightly different
from the representation in the aliases file.  Why doesn't the MTA
normalize them first?!  Lazy-ass piece of...  Why didn't the spec
designers require the MTA to normalize its input, to save me this
headache?"

> When this draft is ready we can look at a way to downgrade to
> legacy ASCII e-mail. But as we here require all MTAs/MUAs handling
> international mailboxes to be upgraded, we can use a simpler
> downgrading to ASCII than IMAA as we only need the ASCII world to see
> international local part as an opaque ASCII string.

I don't see how the downgrading is going to get a lot simpler than IMAA.
You're going to need IDNA for the domain part so that ASCII-only MUAs
can reply to messages (which involves looking up the domain in DNS).
That means you already need Punycode and Nameprep, which are the two
main sources of complexity in IMAA.

Simon Josefsson <[email protected]> wrote:

> adopting the ASCII-encode approach risk decreasing the quality of
> protocols that do not have the same restrictions for which IDNA/IMAA
> was developed.  Instead of using Unicode and UTF-8 directly for
> internationalized strings, it could be tempting to propose that
> protocols should use ASCII-encoded Unicode a'la IDNA/IMAA because it
> is used elsewhere.  The argument is that IDNA/IMAA will "leak" into
> the protocol, so you better handle it somehow.

In protocols that are accessible to legacy software, ACE forms *will*
leak in, and therefore they better be handled correctly.

In new protocols that are accessible only to new software, it would be
possible to require that software to act as a gatekeeper to prevent ACE
forms from leaking in.  That might make life easier for internal agents
that don't normally interact with users, because they wouldn't need to
have ToASCII and ToUnicode.  User-visible agents, however, would still
want those operations, to handle cases where users manually copy ACE
forms from other applications.

AMC