The dates are in UTC. 2 am on the 11th in UTC is the 10th in PDT :) Paul

10 апр. 2018 г., в 3:51 ПП, Mark Svancarek via UA-EAI <ua-eai@icann.org> написал(а):

The time-zones look right, but the days seem off (for Seattle). I think we have a call tonight at 19:00 (3 hours from now) but today is 10th, not 11th. Then we have two calls tomorrow (12:00 and 19:00), April 11th.

From: Don Hollander <don.hollander@icann.org> Sent: Tuesday, April 10, 2018 15:13 To: Don Hollander <don.hollander@icann.org>; Mark Svancarek <marksv@microsoft.com>; John Levine <john.levine@standcore.com>; Dina Solveig Jalkanen <icann@thomascovenant.org>; Abdalmonem Tharwat Galila <agalila@mcit.gov.eg>; HEALTH Yao <yaojk@cnnic.cn>; Dr Ajay Data <ajay@data.in>; ua-eai@icann.org; Lars Steffen <lars.steffen@eco.de>; Ram Mohan <d8f546ce-cfbb-4a97-91f8-e7905fd8b341@pexch112.icann.org> Subject: EAI Reading Call

There’s been some question about the schedule for the rest of the Close Reading of the EAI document.

Not everyone uses Outlook and the call times don’t always seem to translate correctly.

So, Here’s the schedule as best I can figure out the time-zones.

Date/Time UTC New York Seattle Wellington Beijing Delhi Cairo Finland Germany April 10 19:00 UTC 15:00 12:00 7:00 3:00 AM 12:30AM 21:00 22:00 21:00 April 11 02:00 UTC 22:00 19:00 14:00 10:00 7:30 AM 4:00 AM 4:00 AM 5:00 AM April 11 19:00 UTC 15:00 12:00 7:00 3:00 AM 12:30AM 21:00 22:00 21:00 April 12 02:00 UTC 22:00 19:00 14:00 10:00 7:30 AM 4:00 AM 4:00 AM 5:00 AM

• Thanks also for those who told me that Skype doesn’t work for them • We’ll use a dial in service • Dial in codes can be found https://mtginfo.pgi.com/globalcallmanagement.asp?bwebid=9820041&cid=da69e6bcd7e85a14d779fce84d4d&confid=da6ee6bfd7e65a11d77afcef4d4d82d34256&brandid=1[mtginfo.pgi.com] • Access Code is 278 571 0613 • Here are some present links: US tel://1-605-475-5619,*,,2785710613# NZ: tel://0800-440-096,*,,2785710613# HK tel://800-901-914,*,,2785710613# UK tel://0800-358-6387,*,,2785710613# DE tel://0800-588-9171,*,,2785710613# CN Tel://86-10-5667-0006,*,, 2785710613# IN tel://180030101589,*,,2785710613#

A reminder that the link to the document ishttps://docs.google.com/document/d/14uH58SF6U9B2I6eRGN_ldsvESSuCbKKlSWc1OiLxOdg/edit[docs.google.com]

My skype address remains don_hollander – so if you can’t get in when you’re expect to, let me know.

Don

Don Hollander Secretary General – UASG Skype: Don_Hollander

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://mm.icann.org/mailman/listinfo/ua-eai

Jiankang Yao writes:

Some readers may still prefer punycode. Can we list some detail reasons for why not?

Perhaps the most important reason is that we have a forty-year history of email addresses being printable and displayable in the same form. Your address is yaojk@cnnic.cn, and that's both the way it's displayed to humans and the way it's used when computers talk protocol to each other. There's a LOT of software that assumes that it can display addresses as written, in every programming language. Some software written in languages for which there is no punycode library available. Some software written in ways which makes it difficult to integrate punycode, even if a library is available. Some software that would be expensive to upgrade (companies like Oracle charge steep fees to upgrade their databases, and old version of Oracle don't support punycode). You might not think that Oracle would need punycode? But it would. And Microsoft Excel too. People make SQL tables or Excel sheets containing tables of names, addresses and phone numbers. If an address is either readable or usable, but not both, then it doesn't go well into those SQL databases or Excel sheets. Arnt

Paul Borokhov writes:

Isn’t this just an implementation detail? Why should (average) users be exposed to it?

It's an entrenched implementation detail. It's entrenched in both software and average users. The secretary at my children's school is a nice example. She has an Excel sheet with all the parents' email addresses. She expects that she can update that sheet with addresses she sees in parents' mail and also that the addresses are readable and understandable over the phone. Lufthansa's customer service expects the same thing. Both that the addresses they see in my email are readable to me over the phone, and that an address I read to them over the phone is usable to send me mail. And so on and so forth. Jiankang wrote that some readers may prefer punycode. But that doesn't matter to senders, because some other readers reject punycode. Some customer service representative would see Don's new email address (from the attached screenshot) and say "Mr, Hollander, I'm afraid there appears to be an arror with your email address. Is tee oh aye at ex enn hyphen hyphen enn que pee you kay aye pee you kay aye dot enn zed correct? Do you perhaps have another address we can use?" Authors of software must assume that sending a punycoded address risks being rejected by some recipients. Arnt

Agree that explaining motivations can clarify a text in some cases. My comments: -- Punycode is typeable, but also phishy and error-prone. There is no reason to believe that they can easily be used by anyone in any language. -- Anecdote: I previously owned Product Keys for Microsoft (those 25-alphanumeric stings that one would manually enter when installing or activating software). We found that increasing the number of characters from 15 --> 20 --> 25 generated a massive increase in support calls from people who typed them incorrectly. The error rate, already high for English-speakers, was *much* higher outside of the "ASCII-zone". Removing visually-similar (allowing "B" but not "D", disallowing both "I" and "1", for example) reduced the error rate, but not entirely. -- Many of us believe that most EAI usage will be between people and entities which most commonly use the same scripts. Inability to read or type or pronounce the characters and labels is reduced in such cases. -- A goal of UASG is to encourage large corps like Lufthansa that they should allocate resources to dealing with these issues. Large corps understand that adding such support implies investments elsewhere (updating a website involves not just web developers, but content creators, support staff, and IT staffers and LOB application developers). Your example of phone support having to understand how to process macrons is something that would plausibly need to be updated as well. -- These days the scripts that the phone support folks work from are increasingly augmented with AI, MT and bots, so it's not unreasonable to think this is manageable. -----Original Message----- From: UA-EAI <ua-eai-bounces@icann.org> On Behalf Of Paul Borokhov Sent: Thursday, April 12, 2018 10:06 To: Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> Cc: Dina Solveig Jalkanen <icann@thomascovenant.org>; Ram Mohan <d8f546ce-cfbb-4a97-91f8-e7905fd8b341@pexch112.icann.org>; ua-eai@icann.org Subject: Re: [UA-EAI] some notes Re: EAI Reading Call As Jiankang said I don’t want to re-argue this point, since I’m not convincing anyone, but the document should explain the motivations for those being introduced to the topic for the first time. See below.

12 апр. 2018 г., в 12:45 ДП, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> написал(а):

Paul Borokhov writes:

...

Isn’t this just an implementation detail? Why should (average) users be exposed to it?

It's an entrenched implementation detail.

It's entrenched in both software and average users. The secretary at my children's school is a nice example. She has an Excel sheet with all the parents' email addresses. She expects that she can update that sheet with addresses she sees in parents' mail and also that the addresses are readable and understandable over the phone.

Lufthansa's customer service expects the same thing. Both that the addresses they see in my email are readable to me over the phone, and that an address I read to them over the phone is usable to send me mail.

And so on and so forth.

Jiankang wrote that some readers may prefer punycode. But that doesn't matter to senders, because some other readers reject punycode. Some customer service representative would see Don's new email address (from the attached screenshot) and say "Mr, Hollander, I'm afraid there appears to be an arror with your email address. Is tee oh aye at ex enn hyphen hyphen enn que pee you kay aye pee you kay aye dot enn zed correct? Do you perhaps have another address we can use?»

What’s the alternative? «Mr. Hollander, did you say your address contains the letter z with a line over it? I’m sorry, I’m afraid I don’t even know how to type that on my keyboard». How would I explain to a Lufthansa representative that my email address is борохов@почта.рус? Punycode is typeable and readable on any keyboard in any language on a machine that’s connected to the internet today (it has to be). Anything else isn’t.

Authors of software must assume that sending a punycoded address risks being rejected by some recipients.

Arnt <don-hollander-datamail.png>

_______________________________________________ UA-EAI mailing list UA-EAI@icann.org https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmm.icann.or...

Hello,

Some notes for EAI reading call: 1) page 12 " for a variety of reasons, a UTF-8 local-part cannot be encoded as punycode or an A-label. Some readers may still prefer punycode. Can we list some detail reasons for why not?

Do you mean for your own users or for others? For your own users you can do whatever you want with local parts including punycoding them, but since punycode looks like random text the addresses will be very hard to remember or to tell people. For others, it won't work because the punycoded address isn't the same mailbox as the UTF-8 address.

I remebered that the normalization issues had been discussed in EAI WG. the suggestion is that we can not do the normalization to the local part of the email address. different normalization may produce different result for the local part, which may lead to different local part the owner may not recognize too. So only the email owner system may do some normalization to his own address, can not deal with other system produced EAI address.

Quite right, I'll put in something about that. Regards, John Levine, john.levine@standcore.com Standcore LLC