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 1. 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]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mtginfo.pgi.com_globalcallmanagement.asp-3Fbwebid-3D9820041-26cid-3Dda69e6bcd7e85a14d779fce84d4d-26confid-3Dda6ee6bfd7e65a11d77afcef4d4d82d34256-26brandid-3D1&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=M_Un6RFz5LRZV8rIed13YQifASTDMGCS1znWtsRdnrM&s=YlfPY6XcDmFc1RZ9h_2I6oyNRE0gtSBWSxA3y7Mo6Us&e=> * Access Code is 278 571 0613 * Here are some present links: US tel://1-605-475-5619,*,,2785710613#<tel://1-605-475-5619,*,,2785710613/> NZ: tel://0800-440-096,*,,2785710613#<tel://0800-440-096,*,,2785710613/> HK tel://800-901-914,*,,2785710613#<tel://800-901-914,*,,2785710613/> UK tel://0800-358-6387,*,,2785710613#<tel://0800-358-6387,*,,2785710613/> DE tel://0800-588-9171,*,,2785710613#<tel://0800-588-9171,*,,2785710613/> CN Tel://86-10-5667-0006,*<tel://86-10-5667-0006,*/>,, 2785710613# IN tel://180030101589,*,,2785710613#<tel://180030101589,*,,2785710613/> A reminder that the link to the document is https://docs.google.com/document/d/14uH58SF6U9B2I6eRGN_ldsvESSuCbKKlSWc1OiLxOdg/edit[docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_14uH58SF6U9B2I6eRGN-5FldsvESSuCbKKlSWc1OiLxOdg_edit&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=M_Un6RFz5LRZV8rIed13YQifASTDMGCS1znWtsRdnrM&s=8aFkLeYC_QZJ1vOojSFovWpypp6vjoOStyzNxmKHvHQ&e=> 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
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 1. 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]<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__mtginfo.pgi.com_globalcallmanagement.asp-3Fbwebid-3D9820041-26cid-3Dda69e6bcd7e85a14d779fce84d4d-26confid-3Dda6ee6bfd7e65a11d77afcef4d4d82d34256-26brandid-3D1%26d%3DDwMFAg%26c%3DFmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM%26r%3DYI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo%26m%3DM_Un6RFz5LRZV8rIed13YQifASTDMGCS1znWtsRdnrM%26s%3DYlfPY6XcDmFc1RZ9h_2I6oyNRE0gtSBWSxA3y7Mo6Us%26e%3D&data=02%7C01%7Cmarksv%40microsoft.com%7Ca44cdd95c5ea4e95840a08d59f303960%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636589951835877697&sdata=Q3xDTxYLaLpnL9cDLCOa8qfWJX1prmu41VwpW56%2F8wA%3D&reserved=0> * Access Code is 278 571 0613 * Here are some present links: US tel://1-605-475-5619,*,,2785710613#<tel://1-605-475-5619,*,,2785710613/> NZ: tel://0800-440-096,*,,2785710613#<tel://0800-440-096,*,,2785710613/> HK tel://800-901-914,*,,2785710613#<tel://800-901-914,*,,2785710613/> UK tel://0800-358-6387,*,,2785710613#<tel://0800-358-6387,*,,2785710613/> DE tel://0800-588-9171,*,,2785710613#<tel://0800-588-9171,*,,2785710613/> CN Tel://86-10-5667-0006,*<tel://86-10-5667-0006,*/>,, 2785710613# IN tel://180030101589,*,,2785710613#<tel://180030101589,*,,2785710613/> A reminder that the link to the document is https://docs.google.com/document/d/14uH58SF6U9B2I6eRGN_ldsvESSuCbKKlSWc1OiLxOdg/edit[docs.google.com]<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Furldefense.proofpoint.com%2Fv2%2Furl%3Fu%3Dhttps-3A__docs.google.com_document_d_14uH58SF6U9B2I6eRGN-5FldsvESSuCbKKlSWc1OiLxOdg_edit%26d%3DDwMFAg%26c%3DFmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM%26r%3DYI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo%26m%3DM_Un6RFz5LRZV8rIed13YQifASTDMGCS1znWtsRdnrM%26s%3D8aFkLeYC_QZJ1vOojSFovWpypp6vjoOStyzNxmKHvHQ%26e%3D&data=02%7C01%7Cmarksv%40microsoft.com%7Ca44cdd95c5ea4e95840a08d59f303960%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636589951835887705&sdata=3Oa67qw8W6sdEtrDlOYS6Ugn4RauAAmo2g%2Ffywog%2BWI%3D&reserved=0> 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
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
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? 2) page 14, " that is, any legacy sender can send to an EAI recipient. " If an EAI recipient is an EAI address, legacy sender can not send the message to EAI recipient. so the sentence may be changed to " that is, any legacy sender can send to an EAI recipient if an EAI recipient uses an legacy address." We may refine this paragraph again. 3) page 15 " EAI mail systems can be similarly flexible. The rules for what characters are considered equivalent can differ even among languages written in the same script (e.g., Swedish upper and lower case differ from Turkish upper and lower case). The rules will certainly differ from one system to another, and may even have to differ from one mailbox to another depending on the language of the mailbox��s user. See the PRECIS documents for advice on normalizing incoming mail addresses using the various profiles. " 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. Best regards Jiankang Yao From: Don Hollander Date: 2018-04-11 06:12 To: Don Hollander; Mark Svancarek; John Levine; Dina Solveig Jalkanen; Abdalmonem Tharwat Galila; yaojk (yaojk@cnnic.cn); Dr Ajay Data; ua-eai@icann.org; Lars Steffen; Ram Mohan 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 UTCNew YorkSeattleWellingtonBeijingDelhiCairoFinlandGermany April 10 19:00 UTC15:0012:007:003:00 AM12:30AM21:0022:0021:00 April 11 02:00 UTC22:0019:0014:0010:007:30 AM4:00 AM4:00 AM5:00 AM April 11 19:00 UTC15:0012:007:003:00 AM12:30AM21:0022:0021:00 April 12 02:00 UTC22:0019:0014:0010:007:30 AM4:00 AM4:00 AM5: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 is https://docs.google.com/document/d/14uH58SF6U9B2I6eRGN_ldsvESSuCbKKlSWc1OiLxOdg/edit[docs.google.com] My skype address remains don_hollander �C so if you can��t get in when you��re expect to, let me know. Don Don Hollander Secretary General �C UASG Skype: Don_Hollander
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
11 апр. 2018 г., в 12:18 ДП, Arnt Gulbrandsen <arnt@gulbrandsen.priv.no> написал(а):
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.
Isn’t this just an implementation detail? Why should (average) users be exposed to it?
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
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>
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...
On Thursday 12 April 2018 18:05:46 IST, Paul Borokhov wrote:
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 борохов@почта.рус?
Uh, if you dial Lufthansa customer service, someone in Moscow answers the phone, Don's call is answered by someone in Auckland. More generally, EAI is first and foremost for people who use computers and are not friends with the latin alphabet. Such people are going to call or write to Lufthansa's _local_ customer service, or customer service of _local_ companies. In case of Russians, this means they will talk to people who can spell the name борохов and also the email address борохов@почта.рус. This also means that Russians who aren't comfortable using A-Z have a problem communicating with New Zealanders. So what? They have that problem anyway, it's not a problem that an address format can solve. Arnt
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
From: John Levine Date: 2018-04-11 22:29 To: Jiankang Yao CC: Don Hollander; Mark Svancarek; ua-eai@icann.org Subject: Re: some notes Re: EAI Reading Call
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.
If we can list some reasons for readers in the document, they may not ask us to recommend some punycode conversion again. I think that Ajay and Edmon had discussed this issue in the January EAI meeting. Jiankang Yao
The next reading call is in 35 minutes from now. We will switch to Skype. I'm Don_hollander on skype. Please let me know if you would like me to add you to the call. I want to switch to Skype because a) It's usually better quality, b) It's cheaper, and c) The person who asked that we NOT do Skype hasn't participated in any of the call with a dial-up number. Don From: Don Hollander Sent: Wednesday, 11 April 2018 10:13 AM 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>; yaojk (yaojk@cnnic.cn) <yaojk@cnnic.cn>; Dr Ajay Data <ajay@data.in>; ua-eai@icann.org; Lars Steffen <lars.steffen@eco.de>; Ram Mohan <rmohan@afilias.info> 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 1. 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]<https://urldefense.proofpoint.com/v2/url?u=https-3A__mtginfo.pgi.com_globalcallmanagement.asp-3Fbwebid-3D9820041-26cid-3Dda69e6bcd7e85a14d779fce84d4d-26confid-3Dda6ee6bfd7e65a11d77afcef4d4d82d34256-26brandid-3D1&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=M_Un6RFz5LRZV8rIed13YQifASTDMGCS1znWtsRdnrM&s=YlfPY6XcDmFc1RZ9h_2I6oyNRE0gtSBWSxA3y7Mo6Us&e=> * Access Code is 278 571 0613 * Here are some present links: US tel://1-605-475-5619,*,,2785710613#<tel://1-605-475-5619,*,,2785710613/> NZ: tel://0800-440-096,*,,2785710613#<tel://0800-440-096,*,,2785710613/> HK tel://800-901-914,*,,2785710613#<tel://800-901-914,*,,2785710613/> UK tel://0800-358-6387,*,,2785710613#<tel://0800-358-6387,*,,2785710613/> DE tel://0800-588-9171,*,,2785710613#<tel://0800-588-9171,*,,2785710613/> CN Tel://86-10-5667-0006,*<tel://86-10-5667-0006,*/>,, 2785710613# IN tel://180030101589,*,,2785710613#<tel://180030101589,*,,2785710613/> A reminder that the link to the document is https://docs.google.com/document/d/14uH58SF6U9B2I6eRGN_ldsvESSuCbKKlSWc1OiLxOdg/edit[docs.google.com]<https://urldefense.proofpoint.com/v2/url?u=https-3A__docs.google.com_document_d_14uH58SF6U9B2I6eRGN-5FldsvESSuCbKKlSWc1OiLxOdg_edit&d=DwMFAg&c=FmY1u3PJp6wrcrwll3mSVzgfkbPSS6sJms7xcl4I5cM&r=YI0XKyKCabKQi3GVWLvuoyCWjH9WBgEBxLbMnmhSRwo&m=M_Un6RFz5LRZV8rIed13YQifASTDMGCS1znWtsRdnrM&s=8aFkLeYC_QZJ1vOojSFovWpypp6vjoOStyzNxmKHvHQ&e=> 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
participants (6)
-
Arnt Gulbrandsen -
Don Hollander -
Jiankang Yao -
John Levine -
Mark Svancarek -
Paul Borokhov