April 2018 - UA-discuss - lists.iana.org

Is anyone attending the APTLD74 meeting in Tashkent Uzbekistan September 20-21 2018
by Don Hollander April 10, 2018

April 10, 2018

I'm putting together a panel and want to know who on this list might be going. Do please let me know off-list. Thanks. Don

1 0

Re: [UA-discuss] Email Success
by Dr Ajay Data April 10, 2018

April 10, 2018

This is excellent and happy to know that coremail address is now working. Andre, DataMail have been getting request to make signup more simpler and now world wide any one can signup to have an email address in 14 languages using https://mail.datamail.in . Few more languages are being rolled out. Thanks. Dr. Ajay DATA | Founder &amp CEO Get email id like अजय(a)xn--c2bd1gb.xn--h2brj9c in your own language,visit www.xgenplus.com From: Andre Schappo MailId : [80473489]To: ua-discuss Subject: [UA-discuss] Email SuccessDate: 09 Apr 2018 07:35:41 PM I am very pleased to report that I have now successfully sent email from my DataMail 小山(a)xn--wny099c.xn--3ds443g to my Coremail 小山(a)xn--blq510jgwa.xn--io0a7i and vice versa. Email reply at both ends also works fine.It feels like this is a significant step forward.Andr&eacute SchappoDo not Remove:[HID]20180409193541938[-HID]

1 0

UASGTech Tweeting Now, please share.
by Audrey Fery-Forgues April 9, 2018

April 9, 2018

Hello All, Please check out UASGTech’s most recent posts on Twitter: https://twitter.com/UASGTech/status/983425791269617664 And https://twitter.com/UASGTech/status/981706722245992448 Please be sure to follow the @UASGTech twitter handle, retweet, tag and like our posts in order to help spread the word on Universal Acceptance. Thank you, Audrey

1 0

Email Success
by Andre Schappo April 9, 2018

April 9, 2018

I am very pleased to report that I have now successfully sent email from my DataMail 小山(a)xn--wny099c.xn--3ds443g to my Coremail 小山(a)xn--blq510jgwa.xn--io0a7i and vice versa. Email reply at both ends also works fine. It feels like this is a significant step forward. André Schappo

4 4

EAI Document - Close Reading
by Don Hollander April 5, 2018

April 5, 2018

G"day The UASG traditionally performs a close reading of our documents prior to publication. These have been useful to get the text right, clarify any confusion, find spelling and grammar issues, and generally make the readers well informed on the topic. We have been working on the development of an Introduction to Email Address Internationalisation (EAI) that is nearly ready for a close reading. I would like to schedule three one-hour review sessions for next week. My current plan is at UTC 02:00 next Monday, Tuesday and Wednesday. I very much recognise that UTC 02:00 is not a pleasant time for those in Europe, Africa or the Middle East. If there's interest from these geographies to participate, then we'll add some additional sessions that are more accommodating. So, I'm seeking: 1. RSVP's for those who will want to participate (with Adobe Connect still not available, we'll need to find an alternative) 2. Notice from anyone from Europe, Africa or the Middle East who will participate but will find a call at UTC 02:00 a challenge. Do please let me know of the list. Thanks. Don Don Hollander Secretary General - UASG Skype: Don_Hollander

2 1

Re: [UA-discuss] Store domain in Punycode or Unicode?
by Dr Ajay Data April 4, 2018

April 4, 2018

+1 Andre..In XgenPlus Email Server, we store all domains in Unicode only and that`s the way to go. There are many benefits. In this ever changing and fast paced world, Who knows you may have xn-- domains allowed :) thanks Dr. Ajay DATA | Founder &amp CEO Get email id like अजय(a)xn--c2bd1gb.xn--h2brj9c in your own language,visit www.xgenplus.com From: Andre Schappo MailId : [80351250]To: "ua-discuss(a)icann.org" Subject: Re: [UA-discuss] Store domain in Punycode or Unicode?Date: 04 Apr 2018 02:39:51 PM I think the Unicode form should be stored . My reasons for recommending this is a little different . Mostly, I use MySQL and phpMyAdmin for my database work. Storing IDNs and/or EAI addresses in Unicode form has advantages . ① I can search by constructing an SQL query in phpMyAdmin. eg all IDNs which contain 食品 ② I can learn a lot by visual inspection eg I can readily identify text being in Korean, Thai, Sinhala, Chinese, Arabic, Cyrillic scripts I could not do either of the above if only the punycode form is stored . Basically, people can relate to the Unicode form and not the punycode form. So, if it involves people, store in the Unicode form . Actually, there is one punycode label I always recognise, which is .xn--fiqs8s😀 xn--fiqs8s = 中国 = China. I recognise it because I have seen it so many times and I remember when it went live as I posted to IDNforums idnforums.com/forums/26659-china-idn-cctlds-are-live.html That is the only punycode label I recognise . Andr&eacute Schappo On 3 Apr 2018, at 20:51, Andrew Sullivan ajs(a)anvilwalrusden.com> wrote: Hi, On Tue, Apr 03, 2018 at 06:36:03PM +0000, Carolyn Liu via UA-discuss wrote: Today we do not allow customers to enter IDN (in Unicode) in our system (O365), so customers can only enter domain in ASCII, or an IDN in Punycode form . To be clear, this means that domain names with labels of the form xn--[punycode-goes-here] are allowed, but no non-LDH characters are allowed in any domain name label but, after permitting EAI addresses you will accept UTF-8 in the local-part? already brings a challenge for us since mail may come in as UTF8 form . Under EAI, it _will_ come in that form. allow our customers to enter a Unicode domain in O365, and which form we shall store the domain &ndash Unicode or punycode? If you attempt to support IDNA2003 or at least some of the compatibility modes of UTS#46, you effectively need to store both. IDNA2003 can lose information in a round trip from Punycode-form and Unicode-form, so you basically need to know the whole set. This fundamental problem was actually one of the most urgent requirements for IDNA2008, and it`s why some of us remain pretty annoyed with UTS#46 as a strategy since one of its profiles breaks that plan without any suggestion of how it`ll eventually wean people from it. (We didn`t have a weaning suggestion either in the IDNABIS WG, which is why we decided to break the backward compatibility in the few cases, reasoning that pain early in deployment was less bad than pain later.) If you`re restricting your supported domains to IDNA2008, then you don`t have to care: every actual U-label is also exactly one A-label, and conversely. So you can store U-labels or A-labels and get the same result. The usual recommendation is that you store U-labels just because storing A-labels will result in transformation for every user event, and that might have nasty performance effects. 1. Domains in our system is unique, meaning domain is a key. One domain shall only exist once and belong to one customer only . This is true regardless of whether it`s a U-label or A-label: since they`re DNS names they _must_ be unique globally within the DNS. 3. At gateway we need to know whether a domain is in our system. The match logic will be at follows: a. Is domain in system? If so go ahead and accept. b. If not, is it UTF8 form? If so convert to Punycode and search again . This sounds like a round trip plan. Why not just run it through the relevant algorithm and check one time? (LDH-only names will not undergo any transformation. You may need a coalesce function or similar.) 4. Every time when we display, we will always convert the domain to Unicode . This is a reason to prefer U-label forms: no conversion on display, when the user is waiting. 5. This is how DNS supports IDN. A uniform storage will make implementation a lot easier . This is true. But if we allow to store domain in Unicode, then we have to understand those in Punycode and those in Unicode and convert back and force. I understand we always need conversion, but if in only one form we know we always need to covert to the other form, vs we might need to covert both directions everywhere, very costly and very confusing . It is _certainly_ true that you want to pick one, and if you already have A-labels in the sytem then you might have a migration problem. That might be a reason to use A-labels for storage. A -- Andrew Sullivan ajs(a)anvilwalrusden.com Do not Remove:[HID]20180404143951408[-HID]

3 2

Store domain in Punycode or Unicode?
by Carolyn Liu April 4, 2018

April 4, 2018

Hi, I work for Microsoft and own project EAI with O365 mail flow for the most part. We recently announced the support for Phase 1 EAI - that we now support send and receive emails with EAI address. A question, or a challenge I would like to bring your attention and would like to discuss with this group. Today we do not allow customers to enter IDN (in Unicode) in our system (O365), so customers can only enter domain in ASCII, or an IDN in Punycode form. This already brings a challenge for us since mail may come in as UTF8 form. But more importantly, to prepare for the future support of EAI, we must design how to allow our customers to enter a Unicode domain in O365, and which form we shall store the domain - Unicode or punycode? Our proposal is to store domain in punycode. The reasons are at the follows: 1. Domains in our system is unique, meaning domain is a key. One domain shall only exist once and belong to one customer only. 2. We already allow customers to enter domain in Punycode code. 3. At gateway we need to know whether a domain is in our system. The match logic will be at follows: * Is domain in system? If so go ahead and accept. * If not, is it UTF8 form? If so convert to Punycode and search again. 4. Every time when we display, we will always convert the domain to Unicode. 5. This is how DNS supports IDN. A uniform storage will make implementation a lot easier. But if we allow to store domain in Unicode, then we have to understand those in Punycode and those in Unicode and convert back and force. I understand we always need conversion, but if in only one form we know we always need to covert to the other form, vs we might need to covert both directions everywhere, very costly and very confusing. Carolyn

3 2

UASG @ ICANN62 in Panama? SHort answer - no
by Don Hollander April 4, 2018

April 4, 2018

I've had several people write to ask if we'll be having a UASG workshop as part of the ICANN62 meeting in Panama. The answer is no. This is a short, policy focussed meeting. We decided some time ago that we wouldn't have a formal presence Don Don Hollander Secretary General - UASG Skype: Don_Hollander

1 0

UASG Tweeting Now – please share
by Audrey Fery-Forgues April 2, 2018

April 2, 2018

Hello All, Please check out UASGTech’s most recent post on Twitter: https://twitter.com/UASGTech/status/980890671652339713 Please be sure to follow the @UASGTech[twitter.com] handle, retweet, tag and like our posts in order to help spread the word on Universal Acceptance. Thank you, Audrey

1 0

EuroDIG 2018
by Roberto Gaetano April 2, 2018

April 2, 2018

Hi all. Is anybody planning to attend the EuroDIG 2018, that will take place in Tbilisi, Georgia, from 5 to 6 June 2018 (with a Day 0 Monday 4 June)? See https://www.eurodig.org. One of the topics on the agenda is Universal Acceptance. I have volunteered to be the focal point for this topic - which does not mean to be the “expert”, just the person who tries to get things going 😊. As you can see from the session page https://eurodigwiki.org/wiki/WS_06_2018 it is pretty much work in progress. Actually, to be honest, “work just being started, but already late”. I believe that it was an opportunity not to be missed, considering that in Georgia we will have local people attending - who’s native language uses a non-latin script - and wide participation from neighbouring countries and Eastern Europe - that share a similar situation. However, for turning this into a success - or at least a useful session - we need to have participation by people who can explain the technical issues and the way forward. I could do it, but not being an expert I believe that participation from the “real" folks will be instrumental to widen the awareness - and possibly to further participation. Best regards, Roberto

2 1