<minor point> Preventing confusing UI is *possibly* (not definitely) a UASG non-goal, but it's certainly my concern, so it's not something I'd like to gloss over. I suspect that a typical non-user of Arabic would find Arabic script more desirable than boxes or punycode. That's something usability folks can test. Personally, if I were expecting an email from an Arabic-scripting colleague, it would make a big difference to me. <major point> But my goal for EAI is not to enable the people I meet at ICANN, or similar globe-trotters, to exchange emails using unmatching scripts. I am interested in allowing people who use a single script to communicate with confidence to their friends and family and government and banks and insurance companies who use the same script. We have some research indicating that this probably improves usability, confidence and usage overall. In those examples, we are less likely to see these complex scenarios of multiple users replying-all in multiple scripts. Agreeing on a least-worst downgrading solution is important, but it's always going to be a hack and I think it's okay that it will be imperfect. The goal is for full adoption of the spec, at least within non-ASCII script zones. The target users are people who read only one non-ASCII script and who communicate exclusively, or almost exclusively, with others who use that same script. /marksv -----Original Message----- From: John C Klensin [mailto:klensin@jck.com] Sent: Wednesday, November 8, 2017 6:47 AM To: John R. Levine <johnl@iecc.com> Cc: Don Hollander <don.hollander@icann.org>; Joseph Yee <jyee@afilias.info>; HEALTH Yao <yaojk@cnnic.cn>; Mark Svancarek <marksv@microsoft.com>; Barry Leiba <barryleiba@computer.org> Subject: Re: [Ext] EAI Working group Archives --On Wednesday, November 8, 2017 09:22 -0500 "John R. Levine" <johnl@iecc.com> wrote:
On Wed, 8 Nov 2017, John C Klensin wrote:
To illustrate another part of the issue with an example, at least one very well-known operating system make a large distinction between languages the user identifies to the OS as familiar (and installs special IMEs and rendering software for them) and others which may not be handled as well or even treated as potentially hostile. So you are asking for good treatment of languages and scripts that are not identified as known by the user and that is somewhat contradictory of that OS's i19n design philosophy.
It seems to me that people typically configure their computer to handle the languages they understand. If my computer is set up to handle Chinese and Korean, and I get a message in Arabic, it doesn't matter if the Arabic is displayed poorly since I can't read it anyway.
I think that is part of the OS design assumption I referred to. I think it is problematic in some ways, but still quite rational for the reason you give. But "it doesn't matter if X is displayed badly" is inconsistent with Don's "the way the originator intended" formulation; my main point was that one needs to be quite careful about such formulations and their implications. For better or worse, "ok if an unfamiliar language is displayed poorly" also opens up some spoofing risks and other attack vectors that would present less opportunity if proper rendering could be assumed, but I suppose that is not a Universal Acceptance concern (see last week's slide). john