Re: [EAI] Fw: I-D Action:draft-yao-eai-deployment-02.txt

[John C Klensin <[e-mail]>]

--On Thursday, July 09, 2009 14:49 +0800 YAO Jiankang
<[e-mail]> wrote:

> Dear all,
> 
>        updated to version 2.
> 
>    o  rename the section "Sending Server" to "SMTP client"
>    o  rename the section "Recieve Server" to "SMTP server"
>    o  add the new section "Internationalized email domain"
>    o  move and refine the section "Firewall"
>    o  update and refine the texts of this document
> 
>  thanks a lot to S.  Moonesamy for his kind comments to last
> version.

I have skimmed quickly through this version and find two main
issues.  There are also some less significant ones, but, until
the main ones are addressed, I don't think the others are
important.

(1) You indicate that the people you asked, or included in the
tests, want internationalized addresses.  I assume that is true,
but you cannot claim the experiments you have performed as proof
of it unless you describe the population you have sampled,
describe who they were trying to communicate with and how well
they understand the negative aspects of mixed environments, and
so on.

To state this more usefully, I think we all believe that
non-ASCII email addresses are useful and important despite some
disadvantages (otherwise we wouldn't be spending time on this).
At least most of us believe that they are going to be a lot more
useful in homogeneous environments (e.g., a Chinese user
communicating with another Chinese user) than in heterogeneous
ones (e.g., a Chinese user communicating with an Arabic user).
While the protocols may work equally well in both cases, the
opportunities for confusion, phishing, and various bad practices
will be much greater in practice in the heterogeneous ones than
in the homogeneous ones.

Whether we have downgrading or not, whether all systems have
been upgraded to EAI or not, I think we also understand that EAI
is going to lead to an increase in undeliverable mail -- that is
just the nature of alternate representation forms in Unicode--
although Chinese characters used to write Putonghua may be less
affected by these problems than scripts that utilize combining
characters, decorations that may be considered optional, or many
compatibility characters ... or languages for which standardized
orthographies either do not exist or are not widely accepted.

My own guess is that, if a user of one language (and script)
wants to communicate with a user of a very different language,
they will be better off using ASCII addresses for many years in
the future.  Only in the homogeneous cases will there be
reasonable odds of all of the facilities that are not part of
the protocols but that are required for a user perception that
i18mail really works (e.g., font availability, keyboard
compatibility, and ability by the user to conveniently read and
write the relevant language).  Whether you agree or disagree
with that, this document should, IMO, at least discuss the
issues.

Again speaking personally, I will consider i18nemail to be a
huge success if it merely enables better communication within
language communities.  Any enhancements to communication between
such communities would be wonderful, but are not critical to
success and may not even be especially important (you should be
able to deduce my reasoning from the comments above).   Let's
not try to lead the community into disappointment by setting
expectations higher than necessary and appropriate.

(2) Ernie's tests seem to show a rather different picture of
consistent and interoperable behavior, especially where
downgrading is involved, than I would deduce from the very
optimistic Section 10 of this document.  I think this document
needs to be accurate and portray the bad news as well as the
good news.  Without that, it will be impossible for people to
properly evaluate the EAI and make plans without having nasty
surprises.  It would be ok from my standpoint if you described
the bad situations and then explained what was necessary to
avoid them, but something should be said.  In particular, if the
only way to avoid bad effects is for everyone who wants to deal
with i18nemail at all to fully implement the EAI specs, then
that is very important information for us all to have.  I
encourage you to collaborate with Ernie in this area if at all
possible.

regards,
   john