ICANN should be leading by example otherwise it becomes a case of, as my dad used to jokingly say — "Don't do as I do. Do as I tell you". The leading by example in this case is the usage and correct usage of IDNs. The obvious first 3 IDNs that ICANN should register and (correctly) use are icann.संगठन icann.机构 icann.орг all of which translate to icann.org and all of which are, according to whois.icann.org, reserved names. Redirecting the above IDNs to the ASCII icann.org is a good start but is not correct usage of IDNs. The IDNs are not being treated equally to icann.org as they are just being used for temporary transitioning to icann.org To give all icann domain names equal ranking they should all remain in the browser address bar. eg icann.संगठन/news/announcements should not redirect to icann.org/news/announcements icann.संगठन/news/announcements and icann.org/news/announcements should both be treated equally. If ICANN have used relative url addressing throughout their site then it will just work as the Domain Name that will be used and displayed will be the one used for site entry. Another issue is that ICANN is forcing the www prefix by redirection. eg icann.org/news/announcements is redirected by ICANN to www.icann.org/news/announcements This is especially an issue with IDNs as we will end up with mixed script domain names. eg www.小山.中国 instead of 小山.中国 ICANN should not be performing this www prefix redirection. Yes, by all means, redirect from http to https but not the www prefix. Actually, even with straight ASCII Domain Names, I consider it bad practice to force the www prefix by redirection. Don: Actually I was not quite sure how to interpret your sentence "With respect to ICANN using IDN’s, toward what end.". One interpretation is that I need to convince you that ICANN should be using IDNs. I hope that is not the case, because if I have to convince the UASG group that ICANN should be using IDNs then what chance is there with the rest of the world? André Schappo

On 25 Mar 2016, at 17:31, Don Hollander <don.hollander@icann.org> wrote:

Andre,

We know that EAI fails with ICANN - and I suspect many many other organisations.

The good news is that they are working on it - basically waiting for their supplier (I think).

D

...

On 26/03/2016, at 4:48 AM, Andre Schappo <A.Schappo@lboro.ac.uk> wrote:

Thanks to Raed I now have a cool new arabic script email address.

Works fine with gmail

So what of ICANN's mail system.

I sent a test email to ua-international using my arabic email address and subsequently received the error message

➤ SMTPUTF8 is required, but was not offered by host pechora5.icann.org[192.0.46.71]

So, #fail for ICANN wrt EAI

André Schappo

I share some discussions in IETF EAI WG about downgrading. This WG did not design the downgrading mechanism based on the assumption that if most email service providers support EAI, EAI downgrade is not necessary. So my suggestion is that call more email service providers to upgrade their service to support EAI and announce it to support EAI almost together. if google, microsoft, yahoo, qq.com, 163.com and more support EAI almost together, the downgrade will not become a problem. let UASG call all email service providers to form a group and announce it to support EAI on some day together? Jiankang Yao From: Edmon Chung Date: 2016-03-29 13:51 To: 'Don Hollander'; 'Andre Schappo' CC: UA-discuss Subject: Re: [UA-discuss] ICANN EAI infrastructure jumping on this discussion to rekindle an earlier thread with Brent and others about the implementation challenge for EAI, especially with the lack of "downgrading" and some "backwards compatibility". At the meeting in Marrakech, we explored this a bit further and thought maybe some sort of service discovery mechanism to retrieve an alternate address be developed for situations such as mailing lists or forwarded/replied/cc-ed emails especially where additional emails were added to a thread who are not EAI ready. I wonder if anyone on the list is interested to further look into the issue and propose such mechanism(s)... or at least produce some document for what to do in such cases, which could help in the EAI implementation... Edmon

-----Original Message----- From: ua-discuss-bounces@icann.org [mailto:ua-discuss-bounces@icann.org] On Behalf Of Don Hollander Sent: Saturday, 26 March 2016 01:31 AM To: Andre Schappo <A.Schappo@lboro.ac.uk> Cc: UA-discuss@icann.org Subject: Re: [UA-discuss] ICANN EAI infrastructure

Andre,

We know that EAI fails with ICANN - and I suspect many many other organisations.

The good news is that they are working on it - basically waiting for their supplier (I think).

D

...

On 26/03/2016, at 4:48 AM, Andre Schappo <A.Schappo@lboro.ac.uk> wrote:

Thanks to Raed I now have a cool new arabic script email address.

Works fine with gmail

So what of ICANN's mail system.

I sent a test email to ua-international using my arabic email address and subsequently received the error message

➤ SMTPUTF8 is required, but was not offered by host pechora5.icann.org[192.0.46.71]

So, #fail for ICANN wrt EAI

André Schappo