Re: [EAI] Fw: I-D Action:draft-yao-eai-deployment-02.txt
"YAO Jiankang" <yaojk@cnnic.cn> Fri, 10 July 2009 03:19 UTC
Return-Path: <yaojk@cnnic.cn>
X-Original-To: ima@core3.amsl.com
Delivered-To: ima@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 1961A3A6C08 for <ima@core3.amsl.com>; Thu, 9 Jul 2009 20:19:46 -0700 (PDT)
X-Quarantine-ID: <K5KUmi4oDkrl>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER, Duplicate header field: "Message-ID"
X-Spam-Flag: NO
X-Spam-Score: 0.622
X-Spam-Level:
X-Spam-Status: No, score=0.622 tagged_above=-999 required=5 tests=[AWL=0.665, BAYES_00=-2.599, MIME_BASE64_TEXT=1.753, MSGID_FROM_MTA_HEADER=0.803]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id K5KUmi4oDkrl for <ima@core3.amsl.com>; Thu, 9 Jul 2009 20:19:45 -0700 (PDT)
Received: from cnnic.cn (smtp.cnnic.cn [159.226.7.146]) by core3.amsl.com (Postfix) with SMTP id 1D1813A6D13 for <ima@ietf.org>; Thu, 9 Jul 2009 20:19:00 -0700 (PDT)
Received: (eyou send program); Fri, 10 Jul 2009 11:19:11 +0800
Message-ID: <447195951.02932@cnnic.cn>
X-EYOUMAIL-SMTPAUTH: yaojk@cnnic.cn
Received: from unknown (HELO whatisfuture) (127.0.0.1) by 127.0.0.1 with SMTP; Fri, 10 Jul 2009 11:19:11 +0800
Message-ID: <0ba701ca010d$30cacc40$236ff1da@whatisfuture>
From: YAO Jiankang <yaojk@cnnic.cn>
To: John C Klensin <klensin@jck.com>, EAI WG <ima@ietf.org>
References: <447122175.32426@cnnic.cn>, <09b101ca0061$6aef3610$236ff1da@whatisfuture> <447145211.07730@cnnic.cn>
Date: Fri, 10 Jul 2009 11:19:09 +0800
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: base64
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 6.00.2900.3138
X-MIMEOLE: Produced By Microsoft MimeOLE V6.00.2900.3350
Subject: Re: [EAI] Fw: I-D Action:draft-yao-eai-deployment-02.txt
X-BeenThere: ima@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: "EAI \(Email Address Internationalization\)" <ima.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ima>
List-Post: <mailto:ima@ietf.org>
List-Help: <mailto:ima-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ima>, <mailto:ima-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 10 Jul 2009 03:19:46 -0000
Dear John,
thanks a lot for your kind comments.
after reading your comments, we may divide this draft into 2 drafts. the first draft is about EAI deployment guideline.
We can change this current draft's name from "EAI Deployment Practices" to "EAI Deployment guideline".
we can move the section 10 about "EAI tests" to the second draft. we may name this draft with "EAI evaluation and tests "
In this new draft, we can mainly discuss the 2 issues you mentioned and collaborate with Ernie about the issue of EAI test.
more comments are below.
thanks a lot.
YAO Jiankang
CNNIC
----- Original Message -----
From: "John C Klensin" <klensin@jck.com>
To: "YAO Jiankang" <yaojk@cnnic.cn>; "EAI WG" <ima@ietf.org>
Sent: Thursday, July 09, 2009 9:13 PM
Subject: Re: [EAI] Fw: I-D Action:draft-yao-eai-deployment-02.txt
>
>
> --On Thursday, July 09, 2009 14:49 +0800 YAO Jiankang
> <yaojk@cnnic.cn> 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.
CNNIC publish Chinese internet users survey every year.
I will suggest them do this kind survey in the near future.
>
> 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).
according to our simple survey, many users want internationalized addresses to communicate with both chinese and foreigner.
so Ascii address as the alias of internationalized addresse may be a solution. This situation is similar to the situation below:
My name card have both sides, one side with english version is for the foreigner to read; the other side side with chinese version is for chinese to read.
Both sides say the same thing. English version of name card is the translation of Chinese version; Chinese version of name card is the translation of English version.
so the ascii email address (English version) is for foreigner; the chinese email address (chinese version) is for chinese. both email addresses refer to the same email store. It is unlikely that Chinese user will present a name card only with chinese version to Arabic users or American users. similarly, It is unlikely that Chinese email user will present the email address only with chinese version to Arabic email users or American email users. so from this view, the two version email address may coexist in the longrun.
> 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.
>
the WG already solve the problme in the protocol level. some implementation issues need more discussions.
> 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
if the reason is due to unicode, the problem is simialr to the problem IDNAbis encounters.
>-- 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.
+1
>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.
I think that we can discuss the issues in the draft "EAI evaluation and tests "
>
>
> 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.
market demands will promote the EAI.
>
> (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.
>
I think that we can discuss the issues in the draft "EAI evaluation and tests " and collaborate with Ernie.
thanks a lot.
> regards,
> john
>
- [EAI] Fw: I-D Action:draft-yao-eai-deployment-02.… YAO Jiankang
- Re: [EAI] Fw: I-D Action:draft-yao-eai-deployment… John C Klensin
- Re: [EAI] Fw: I-D Action:draft-yao-eai-deployment… YAO Jiankang