--On Tuesday, October 28, 2003 11:12 -0500 Marc Blanchet
<Marc.Blanchet@viagenie.qc.ca> wrote:
> it appears to me that this thread is not very different from
> the idn considerations on usage of idn in the world. So what
> is really new in this discussion?
See the draft.
Quick answer: DNS interfaces really exist at the protocol level,
and a large part of the hypothesis behind IDNA was that it would
be possible, after we had enough implementations, to prevent an
end-user from ever seeing an encoded domain name. That story
just doesn't hold for a special encoding-based (aka MUA-only)
email local part implementation, and maybe not for email
generally. For example, under current rules, an MTA is required
to stuff the name it actually sees in HELO/EHLO and the MAIL
command into various headers. If it is expected to notice that
they have special encodings and decodes them, we've gone rather
far into "the infrastructure is involved", even if the actual
on-the-wire transport is not impacted. If it doesn't do that,
the encodings --both the IDNA domain parts and the special mail
encoding-- are going to be in the user's face, in the most
literal sense of that term.
The similarity of that situation to the early IDN discussions is
the importance of the "what problem are you solving" question.
And it is very clear to me that, for email addresses, the answer
has got to "user sees their own characters in their email
addresses and the email addresses of those whose languages they
speak/ recognize. Users typically don't actually see envelopes.
But seeing, e.g., different forms/codings of an address in the
header "From:" field than appears in "Return-path:" or than
appears in a signature line in the message body, is going to
create real unhappiness. Similarly as has been pointed out in
another context, seeing an address in different from when it
appears in a header than when it (and that header) are
encapsulated in a message/?? body part is just not going to
amuse any user to whom we've said "ok, now you have i18n
strings, enjoy your new found local language capabilities". And
I guess that tells you what I think the problem is that we need
to solve. YMMD.
john