- UA-discuss - lists.iana.org

[UA-discuss] https://www.linkedin.com/pulse/true-multilingual-internet-starts-universal-acceptance-cindy-zhou?trk=hp-feed-article-title-publish
by Don Hollander Feb. 25, 2017

Feb. 25, 2017

Another report on UA… Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

FW: Proposed update of UTS #46, for Unicode domain names
by Mark Svancarek Feb. 25, 2017

Feb. 25, 2017

I don't feel qualified to pass judgement on this update - UA folks, care to chime in? From: root(a)unicode.org<mailto:root@unicode.org> [mailto:root@unicode.org] On Behalf Of announcements(a)unicode.org<mailto:announcements@unicode.org> Sent: Thursday, February 23, 2017 2:40 PM To: announcements(a)unicode.org<mailto:announcements@unicode.org> Subject: Proposed update of UTS #46, for Unicode domain names UTS #46 "Unicode IDNA Compatibility Processing"<http://www.unicode.org/reports/tr46/tr46-18.html> is used by many applications to support internationalized domain names with non-English characters. The proposed update to Version 10.0 regenerates the UTS #46 data files based on new additions to the Unicode repertoire, and adds three new parameters for processing: CheckHyphens, CheckBidi, and CheckJoiners. These parameters allow implementations to reflect current practice in browsers. The note about the use of IDNA2008 now includes the number of "missing" IDNA2008 characters (26,568), and is reworded for clarity. There are two review notes requesting feedback on the use of Joiner characters. For details and information about how to provide feedback, please see Public Review Issue #347<http://www.unicode.org/review/pri347/>. http://blog.unicode.org/2017/02/proposed-update-of-uts-46-for-unicode.html

1 0

Election update...
by Don Hollander Feb. 24, 2017

Feb. 24, 2017

A quick update on the election process: There was one accepted nomination for Chair: Ram Mohan. So, Ram continues in the role for another two years. Congratulations. There were six accepted nominations for the three positions of Vice-Chair: Vice-Chair - Edmon Chung Vice-Chair - Ajay Data Vice-Chair - Christian Dawson Vice-Chair - Jothan Frakes Vice-Chair - Rich Merdinger Vice-Chair - Mark Svancarek I am currently gathering materials from the candidates. Should be done in the next day. Then, I’ll send a link to voting to all subscribers of this UA discuss list (as of the beginning of this week) Voting will be available for a week and then we should have a decision. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

12 12

Universal Acceptance White Paper - Draft for Comment
by Don Hollander Feb. 24, 2017

Feb. 24, 2017

You may recall that last year we commissioned a White Paper to look at the Economic, Social and Cultural value of pursuing Universal Acceptance. Please find attached a draft of the report prepared by Analysys Mason. Your comments would be welcome either on-line or during the UASG Workshop in Copenhagen where we’ll devote some considerable time to it. Please note that this is a draft and is not ripe for public distribution. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

Re: [UA-discuss] [ajay.uasg@data.in] [UA-EAI] Revised UASG013 - Quick Guide to EAI
by Andre Schappo Feb. 23, 2017

Feb. 23, 2017

I have my DataMail account setup using the same method and it works well. So I have, 小山(a)xn--wny099c.xn--3ds443g as my primary and the ascii alias i18n(a)datamail.in<mailto:i18n@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 अजय(a)xn--c2bd4bq1db8d.xn--h2brj9c ajay(a)xn--c2bd4bq1db8d.xn--h2brj9c 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(a)data.in<mailto:ajay@data.in>> wrote: This is what we are doing as of now.. we are calling it Alias. One mail box: My unicode id is - अजय(a)xn--c2bd4bq1db8d.xn--h2brj9c Alias - aj(a)datamail.in<mailto:aj@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(a)icann.org<mailto:ua-discuss@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(a)icann.org<mailto:ua-discuss-bounces@icann.org> [mailto:ua-discuss-bounces@icann.org] On Behalf Of Andre Schappo Sent: Wednesday, February 22, 2017 7:50 AM To: Joseph Yee <jyee(a)afilias.info<mailto:jyee@afilias.info>>; ua-discuss <UA-discuss(a)icann.org<mailto:UA-discuss@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 小山(a)xn--7ovo13by0g.xn--3ds443g<mailto:%E5%B0%8F%E5%B1%B1@xn--7ovo13by0g.xn--3ds443g> andre(a)xn--7ovo13by0g.xn--3ds443g<mailto:andre@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, 🐓(a)xn--7ovo13by0g.xn--3ds443g 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(a)afilias.info<mailto:jyee@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(a)afilias.info<mailto:jyee@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(a)icann.org<mailto:don.hollander@icann.org>> Cc: "ua-eai(a)icann.org<mailto:ua-eai@icann.org>" <ua-eai(a)icann.org<mailto:ua-eai@icann.org>>, Mark Svancarek via UA-Coordination <ua-coordination(a)icann.org<mailto:ua-coordination@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(a)icann.org<mailto:don.hollander@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(a)icann.org<mailto:UA-EAI@icann.org> https://mm.icann.org/mailman/listinfo/ua-eai -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

3 2

Fwd: UA Article
by Don Hollander Feb. 23, 2017

Feb. 23, 2017

> Begin forwarded message: > > From: Baher Esmat <baher.esmat(a)icann.org> > Subject: UA Article > Date: 24 February 2017 at 12:04:10 AM NZDT > > > Colleagues, > > I published this article (in Arabic) about universal acceptance on ICTGATE; an Egyptian online tech portal > ⁨http://ictgate.com/القبول-العالمي-لعناوين-الإنترنت/⁩ <⁨http://ictgate.com/%D8%A7%D9%84%D9%82%D8%A8%D9%88%D9%84-%D8%A7%D9%84%D8%B9%D8%A7%D9%84%D9%85%D9%8A-%D9%84%D8%B9%D9%86%D8%A7%D9%88%D9%8A%D9%86-%D8%A7%D9%84%D8%A5%D9%86%D8%AA%D8%B1%D9%86%D8%AA/⁩> > > Best > Baher Don Hollander Universal Acceptance Steering Group Skype: don_hollander

1 0

Fwd: [UA-EAI] Revised UASG013 - Quick Guide to EAI
by Joseph Yee Feb. 23, 2017

Feb. 23, 2017

Forwarded this to UA-discuss list for broader feedback on the EAI Quick Guide. Best, Joseph ---------- Forwarded message ---------- From: Joseph Yee <jyee(a)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(a)icann.org> Cc: "ua-eai(a)icann.org" <ua-eai(a)icann.org>, Mark Svancarek via UA-Coordination <ua-coordination(a)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(a)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(a)icann.org > https://mm.icann.org/mailman/listinfo/ua-eai > >

4 3

International Mother Language Day
by Ajay DATA Feb. 21, 2017

Feb. 21, 2017

Wishing you all International Mother Language day. I was not even aware about this day till I saw a tweet -from Andre Schappo #InternationalMotherLanguageDay One can have email addresses in Arabic，Bengali，Chinese，Gujarati，Hindi，Marathi，… https://t.co/5co3oIm13w Thank you Andre for very nicely written blog. Best Regards. Ajay Data Email Powered by XgenPlusWorlds Most advanced email.

1 0

UASG Election Nominations Update...
by Don Hollander Feb. 17, 2017

Feb. 17, 2017

This is the last notice before the close off this weekend. The following nominations have been received and accepted: Elections 2017 Chair - Ram Mohan Vice-Chair - Ajay Data Vice-Chair - Jothan Frakes Vice-Chair - Christian Dawson Vice-Chair - Edmon Chung Vice-Chair - Mark Svancarek Vice-Chair - Rich Merdinger Don

1 0

UA Poster
by Don Hollander Feb. 17, 2017

Feb. 17, 2017

We’ve been doing some work on getting a poster designed that we can use at a variety of events. Many thanks to Nicole for her contribution to this and all the other excellent design work that we’ve had. Please find attached a draft. Plan is to produce these at A0 size (e.g. poster size). I would envision making these available at gatherings of software developers and such. Your thoughts are welcome. Don Don Hollander Universal Acceptance Steering Group Skype: don_hollander

5 5