[UA-discuss] Fwd: [UA-EAI] Revised UASG013 - Quick Guide to EAI

[Joseph Yee]

Forwarded this to UA-discuss list for broader feedback on the EAI Quick
Guide.

Best,
Joseph


---------- Forwarded message ----------
From: Joseph Yee <jyee at afilias.info>
Date: Thu, Jan 26, 2017 at 5:14 PM
Subject: Re: [UA-EAI] Revised UASG013 - Quick Guide to EAI
To: Don Hollander <don.hollander at icann.org>
Cc: "ua-eai at icann.org" <ua-eai at icann.org>, Mark Svancarek via
UA-Coordination <ua-coordination at icann.org>


Hi UA-EAI team,

Few comments and questions regarding the quick guide for discussion:

(1)
Client Software (MUA – Mail User Agent)
- Should pass the domain name to the MTA (Mail Transport Agent) in A-Label
format (RFC5890)

The idea of EAI is to allow native Unicode in UTF8 in all mail exchange, is
there any rationale for this recommendation?
This also makes mailbox management more unnecessary complicated when the
next recommendation is 'Should store and display the Mailbox in Unicode'.

(2)
Consider offering mailbox names which conform to the domain name label
generation rules for the selected script.
- Such names are guaranteed to be compatible with the Punycode algorithm.

Punycode is one of many encoding solution, and it (assuming we are talking
about punycode under IDNA2008) has drawback.  This limits the characters
allowed in mailbox name. While some may found it okay, it should be pointed
out.


(3)
Consider offering mailbox names which conform to the domain name label
generation rules for the selected script.
- These email addresses can easily be shared by users with their friends
and colleagues who do not use their same writing method; the colleague or
friend can address email to such an address, or create an address book
entry, using the A-label format.

Since there's a recommendation earlier to offer an all-ASCII email address,
I think this recommendation is not necessary. If one isn't using the same
writing method (or the same language/character), it might be better storing
the all-ASCII name than than the 'A-label' name. It's easier to manage
'josephyee' than 'xn--qoqx77cy1a' which rely on mail client or backend to
render it back properly.

(4)
Upon use, the client MUA software should convert the A-Label to the
appropriate U-Label, at which point the friend or colleague will possess
the EAI formatted email address despite not having a keyboard or IME which
supports the target script.

First, this one is more of a recommendation for mail client section than
mail service provider section.
Second, please see below for a more in depth discussion on the whole
encoding mailbox name.

(5)
How to ensure delivery to non-EAI ready mail systems
- Normalising mailbox names in non-ASCII scripts

If the recipient is non-EAI ready mail systems, normalising mailbox names
would not help.  Non-ASCII characters still exist in the mailbox name after
normalization.

*****
(Note: I'm co-chair of EAI working group at IETF, but I speak as individual
only)

On Encoding (A-label, punycode, etc) mailbox name

At EAI working group, the notion of encoding the UTF8 mailbox name into
pure-ASCII mailbox had been discussed, and there is no recommendation made
on it.  Mailbox management is different from domain management, applying
the same encoding algorithm may sound intuitive as domain name already used
it and seeming of consistent because the same encoding was provided on both
sides of the @ sign. The first drawback, as mentioned above, is the
limitation of characters allowed in local part.  There are legit ASCII
characters/symbols (!#$_) for email that won't make it with A-label. The
second drawback is that some characters being used in human name may be
prohibited under IDNA2008.  There are another category of concerns with
pure punycode algorithm on mailbox name. Also, there are not enough
coverage on ensuring various presentations of mail address to map to the
same mailbox.

I have serious concern on recommending this practice. This practice is
neither mandatory standard nor best common practice, it probably would not
be consistently implemented across mail clients, and I would not be
surprise if some implementer were against this.  While we can recommend to
think-about/adopt encoding practice, I'm concern that we need to expand
more writing to the quick guide.

If there's a strong desire to push for an encoding practice, there's a need
for another in depth writing on pros & cons, deployment and operation
needs, what works & what doesn't.

Best,
Joseph










On Sun, Jan 22, 2017 at 4:33 AM, Don Hollander <don.hollander at icann.org>
wrote:

> Last month I sent out a formatted Quick Guide to EAI.
>
> This resulted in a number of comments from Ajay, Stuart, Mark, Lars &
> Dennis.
>
> These enhancements were mostly focused on the Email Service Provider.
>
> I have revised the source document which is attached.
>
> And for reference, I’m also including the formatted earlier draft.
>
> Could I please get any final comments by the end of this week (25th)?
>
> Thanks.
>
> Don
>
>
>
>
>
>
>
>
>
>
>
>
> Don Hollander
> Universal Acceptance Steering Group
> Skype: don_hollander
>
>
>
>
> _______________________________________________
> UA-EAI mailing list
> UA-EAI at icann.org
> https://mm.icann.org/mailman/listinfo/ua-eai
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170213/5fd57803/attachment.html>