[UA-discuss] [ajay.uasg at data.in] Re: [UA-EAI] Revised UASG013 - Quick Guide to EAI

Thu Feb 23 07:04:52 UTC 2017

This is what we are doing as of now.. we are calling it Alias. 

One mail box: 
My unicode id is - अजय@डाटामेल.भारत
Alias - aj at datamail.in

And it is working well. 

Best Wishes

Ajay Data

On February 23, 2017 11:30:02 AM GMT+05:30, Mark Svancarek via UA-discuss <ua-discuss at icann.org> wrote:
>Andre’s suggestion is a good one and we should probably add it to the
>“things to consider” portion of the document as an option for email
>service providers.
>
>Regarding Joseph’s comments:
>
>1.  I don’t actually recall when we made this suggestion.  It will
>certain work and may improve compatibility with some systems.  Perhaps
>we should make this a consideration rather than a best practice.
>2.  It’s true that use of IDNA will restrict the mailbox name strings
>available.  I posit that the number of valid strings will still be huge
>and that the trade-off is acceptable.
>3.  If an ASCII mailbox alias is offered, then this suggestion is less
>interesting.
>  4.  Move to the mail service provider section.
>  5.  I no longer remember why we suggested normalizing… sorry
>
>From: ua-discuss-bounces at icann.org
>[mailto:ua-discuss-bounces at icann.org] On Behalf Of Andre Schappo
>Sent: Wednesday, February 22, 2017 7:50 AM
>To: Joseph Yee <jyee at afilias.info>; ua-discuss <UA-discuss at icann.org>
>Subject: Re: [UA-discuss] [UA-EAI] Revised UASG013 - Quick Guide to EAI
>
>When I read the Quick Guide to EAI a few days ago I was somewhat
>surprised to see punycode/A-Label used with respect to the
>local-part/mailbox name. Joseph's email has prompted me to respond.
>
>There are many issues to having the local-part as punycode but in this
>email I will focus on a practical working practice that encompasses
>both the (huge) transition problem and the long term. I think a Best
>(Compromise) Practice could be:-
>
>Registration of an internationalised email address would involve
>registration of both a primary unicode local-part and a secondary ASCII
>local-part. The ASCII local-part does not need to be a conversion from
>Unicode to ASCII. Choice of both the Unicode and the ASCII being the
>choice of the registrant. Both the Unicode and the ASCII would name the
>same mailbox.
>
>So, for example, I could register
>
>小山@秋月茶.在线<mailto:小山@秋月茶.在线>
>andre@秋月茶.在线<mailto:andre@秋月茶.在线>
>
>where 小山 is my primary local-part and andre is my secondary local-part.
>
>Local-part aliasing already exists on some mail servers. Using the
>above working practice would enforce an EAI aliasing at the
>registration stage.
>
>Using such a methodology would not restrict the Unicode (mostly) that
>could be used for the local-part. So, for example, 🐓@秋月茶.在线 would be a
>valid email address
>
>I think this working practice could be applied retrospectively. All the
>mail servers with ASCII only local-parts could allow users to create
>Unicode local-part aliases thus resulting in both a Unicode local-part
>and an ASCII local-part. This would be offered to users after the mail
>server software has been updated to support EAI
>
>André Schappo
>
>On 13 Feb 2017, at 21:41, Joseph Yee
><jyee at afilias.info<mailto:jyee at afilias.info>> wrote:
>
>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<mailto: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<mailto:don.hollander at icann.org>>
>Cc: "ua-eai at icann.org<mailto:ua-eai at icann.org>"
><ua-eai at icann.org<mailto:ua-eai at icann.org>>, Mark Svancarek via
>UA-Coordination
><ua-coordination at icann.org<mailto: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<mailto: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<mailto:UA-EAI at icann.org>
>https://mm.icann.org/mailman/listinfo/ua-eai

-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20170223/fc0bf646/attachment.html>