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

Thu Feb 23 16:24:16 UTC 2017

Thanks André

Off course we do support both the examples however this ascii at utf is more of a wish that practical use.

If email server supports UTF mailbox,  all sorts of example are supported and must be suppprtee like we do in our solution xgenplus , however some server do not support UTF then either part in UTF won't work, so ascii at utf do not seem to solve any UA issue .

On February 23, 2017 8:45:36 PM GMT+05:30, Andre Schappo <A.Schappo at lboro.ac.uk> wrote:
>
>I have my DataMail account setup using the same method and it works
>well.
>
>So I have, 小山@电邮.在线 as my primary and the ascii alias
>i18n at datamail.in<mailto:i18n at datamail.in> as my ascii secondary. Thus
>the aliasing is on the whole email address.
>
>I consider the local-part should have it's own aliasing. So, taking
>Ajay's email address, local-part aliasing would give
>
>अजय@डाटामेल.भारत
>ajay@डाटामेल.भारत
>
>and we retain the same domain name.
>
>Both whole email address aliasing and local-part aliasing could
>co-exist
>
>André Schappo
>
>On 23 Feb 2017, at 07:04, Ajay Data <ajay at data.in<mailto:ajay at data.in>>
>wrote:
>
>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<mailto: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<mailto: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>
>[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<mailto:jyee at afilias.info>>;
>ua-discuss <UA-discuss at icann.org<mailto: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:%E5%B0%8F%E5%B1%B1 at xn--7ovo13by0g.xn--3ds443g>
>
>andre@秋月茶.在线<mailto:andre at xn--7ovo13by0g.xn--3ds443g>
>
>
>
>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.

-- 
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/501bf0bf/attachment.html>