Re: draft-klensin-emailaddr-i18n-00

Adam M. Costello 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.

By international domain names I mean a domain name containg non-ASCII
characters. The same for e-mail addresses.

The problem with IDNA and IMAA is that the definition is defined in terms
of an ASCII form and the rules applied to converting to ASCII.

A domain name with mixed case is an international domain name, but that
is not the definition of IDNA.
IMAA also make changes to the e-mail address resulting in a subset of the
possible international e-mail addresses.

I think a international e-mail addess or domain names should be defined
in character semantic, not ASCII encoding rules.

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

By fixing my MTA or DNS server I can support both legacy and
internationalised applications as well as giving transition support
for application. All new applications do not need to handle legacy
as the enhanced MTA/DNS server does the up/downgrading for it.

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

The implementation cost is much lower it we agree to use the same format
"on the wire". At each end we only need to implement translation between
"on the wire format" and "internal format".
By having many "on the wire" formats, the code gets much more complex and
increases CPU needs and memory needs.
I think W3C have written some information about "early" normalisation.
Also as messages may pass many systems/applications on the way from sender
to destination, requiring normalised data results in only sender and
possibly final recipient (if not wanting to use normalised data) need to
change the normalisation. All hops between need not do additional
normalisation work, and if they want to do some filtering using some
internal format they only have one "on the wire" format to convert from.

So I can clearly see that implementation cost is much lower, and system
resources is lower, if we only have one "on the wire" format.

   Dan