Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

From: "abel" <[email-masked]>
Date: Fri, 1 Dec 2006 15:25:39 +0800

----- Original Message ----- 
From: "Soobok Lee" <[email-masked]>
To: "Yao Jiankang" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 01, 2006 12:29 PM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

> On Fri, Dec 01, 2006 at 11:17:36AM +0800, Yao Jiankang wrote:
> >
> > ----- Original Message ----- 
> > >
> > > How about having some guideline to *ban* on embedding any
data/instruction
> > > into the NON-ASCII localpart, since  NON-ASCII lables are most for
humans
> > > not for machines. They will use ASCII localpart for that purpose. No
harm
> > > at all.
> >
> > yes, I also considered this issue about *ban* on embedding any
data/instruction
> >  into the NON-ASCII localpart before.
> > on another thought, *ban" will also cause some problems and has some
inconvenience.
> > for example, I can use sub-address such as [email-masked]
before  EAI protocol is published.
> > but I can not use sub-address such as [Chinese Character yao]+ietf@IDN
after  EAI protocol is published.
> >
> > so after EAI protocols are published, it is not our design aim that
some email address form will be dis-allowed.
>
> in your example, "+" can be added as a legal delimiter for localparts.
/=_! can be added as legal delimiters likewise.
> For my example, "[SOOBOK in UTF8].[LEE in UTF8][email-masked] can be
autoconverted into
> "[email-masked]. No loss of information. dot
and + and underbar was not lost.
> The receiving SMTP server parses it back to NONASCII in order to find
data/instruction
> for whitelisting filtering. Even the receiving server can work directly
> on [email-masked]   without NON-ASCII version if it is
already registered
> as an ascii *alias* for NON_ASCII in the server alias database.
> Still I can find no problem at all.
I very agree Soobok views, But this was a violation of the framework
requirements.
Harald said: that's a local decision about automatic converting.
Even if there are delimters.

Abel

_______________________________________________
IMA mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ima

---

From: "Yao Jiankang" <[email-masked]>
Date: Fri, 1 Dec 2006 15:33:06 +0800

----- Original Message ----- 
From: "abel" <[email-masked]>
To: "Soobok Lee" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, December 01, 2006 3:25 PM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

> I very agree Soobok views, But this was a violation of the framework

Yes, it is a violation of the framework  requirements.

> Even if there are delimters.

Agree. it is a local decision, not our protocol decision.

Yao Jiankang

---

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 16:45:44 +0900

> Agree. it is a local decision, not our protocol decision.

Can you suggest the exact paragraph in the framework or other drafts
about local decision ?  Or articles in this WG?
This will help us and audiences to understand that issue.

Soobok

---

From: "Yao Jiankang" <[email-masked]>
Date: Fri, 1 Dec 2006 16:45:29 +0800

----- Original Message ----- 
From: "Soobok Lee" <[email-masked]>
To: "Yao Jiankang" <[email-masked]>
Cc: <[email-masked]>; "abel" <[email-masked]>
Sent: Friday, December 01, 2006 3:45 PM
Subject: Re: [EAI] i18n of localpart versus i18n of email RFC standards

> about local decision ?  Or articles in this WG?

for example, this link: http://www1.ietf.org/mail-archive/web/ima/current/msg00995.html

Yao Jiankang
CNNIC

---

From: Soobok Lee <[email-masked]>
Date: Fri, 1 Dec 2006 19:23:25 +0900

> for example, this link: http://www1.ietf.org/mail-archive/web/ima/current/msg00995.html

I found also this sentences in the beginning part of  EAI WG charter.
<quote>
  Since early in the effort to internationalize domain names, which
resulted in the standards associated with IDNA, it has been
understood that internationalization of email address local parts is
required. At the same time, email address internationalization poses
a series of special problems. 

<look here>
Constraints on the interpretation of
local-parts by any system other than the final delivery one make
address encoding nearly impossible. 
</look here>
The need to use addresses in both
the email envelope and in header fields, and to do so in ways that are
at least compatible, suggests that this is not a simple and isolated
problem.
</quote>

Would anyone explain the reason behind this decision ?

Soobok

---

From: Yangwoo Ko <[email-masked]>
Date: Fri, 01 Dec 2006 20:06:57 +0900

> Would anyone explain the reason behind this decision ?

<quote from RFC 2821>
   Consequently, and due to a
   long history of problems when intermediate hosts have attempted to
   optimize transport by modifying them, the local-part MUST be
   interpreted and assigned semantics only by the host specified in the
   domain part of the address.
<end of quote>

For discussion why it is impractically difficult to correctly encode
local part is found at IMAA mailing list. I guess that nobody seems
to repeat that work.

Additional comments on "encoding by local policy". I think that
my addresses are also encoded by ACE whose algorithm resides in
my brain. I locally decided to map my name to all ASCII name. And
it has worked well so far.

Regards