Just clarifying before I agree 😊, what is an example of the second case where it's an unreasonable expectation? -----Original Message----- From: barryleiba@gmail.com [mailto:barryleiba@gmail.com] On Behalf Of Barry Leiba Sent: Wednesday, November 8, 2017 1:08 PM To: Mark Svancarek <marksv@microsoft.com> Cc: John C Klensin <klensin@jck.com>; John R. Levine <johnl@iecc.com>; Don Hollander <don.hollander@icann.org>; Joseph Yee <jyee@afilias.info>; HEALTH Yao <yaojk@cnnic.cn>; ua-eai@icann.org Subject: Re: [Ext] EAI Working group Archives Mark, Don, I guess the bottom line is this: - If the goal of UA is to ensure that web sites, email systems, apps, and other doo-dads will accept any domain name and any email address, and things will mostly work as mostly expected most of the time, the goal is probably reasonable and feasible. - If the goal of UA is that users of any domain name and any email address should be able to use those and get what they expect to see essentially all the time, the goal probably can't be reached. The main point: we can make most things work enough of the time that it will be all be useful in general. There will always be failures, and we can hope to minimize them and to make the results tolerable. Barry On Thu, Nov 9, 2017 at 12:52 AM, Mark Svancarek <marksv@microsoft.com> wrote:
If you mean that different writers might prioritize different use cases, I agree. If you mean that different writers might consider certain robustness scenarios differently (e.g. whether one should accept punycode in the local part, where it is undefined), I can understand that, too.
But I assume there is a core protocol defined in the documents which we can all agree unequivocally must be supported in a specific way... is that not the case? If that is the case, I would write tests which exercise that functionality explicitly and cover the robustness cases with caveats and warnings.
-----Original Message----- From: John C Klensin [mailto:klensin@jck.com] Sent: Wednesday, November 8, 2017 12:00 PM To: Barry Leiba <barryleiba@computer.org>; John R. Levine <johnl@iecc.com> Cc: Mark Svancarek <marksv@microsoft.com>; Don Hollander <don.hollander@icann.org>; Joseph Yee <jyee@afilias.info>; HEALTH Yao <yaojk@cnnic.cn>; ua-eai@icann.org Subject: Re: [Ext] EAI Working group Archives
--On Wednesday, November 8, 2017 22:41 +0400 Barry Leiba <barryleiba@computer.org> wrote:
At some point, you just lose. If I send you Arabic text and you don't have an Arabic font, unless you plan to do something heroic like send it to a faraway rendering service that returns a png image, what are you going to do?
Of course. But the main point is that most modern systems are able to display a good deal of the commonly used scripts without extra downloads. My iPad, configured for dead-standard English, can still display Wiki pages in Russian and Greek and Hebrew and Arabic and Chinese and Japanese and Korean and.... If I want a nicer Chinese font, I can deal with that myself, but the basic support is there and I don't see boxes. I even get Mongolian and Thai.
Right... about this and several prior comments, however three observations:
(1) A system can have (and be able to display) Arabic fonts without having the slightest clue about rendering, either at the bidi level (which is needed as soon as, e.g., digits appear in the text, not just for mixed-script or embedded script text) or with the much greater complexity (and interactions with other assumptions) implied by proposed UTR#53. Personally, I agree that it still much better than boxes: not only is some clue about what I've looking at useful (e.g., I can rather easily tell Arabic script from Devanagari script even though I cannot read either) but any given box is almost guaranteed to be confusable with any other box.
(2) My main concern in raising this set of issues is to illustrate that it is very important that the Universal Acceptance effort be extremely clear about what it is talking about and what its expectations are, especially given my belief (and, apparently, given other comments above desires and preferences, the beliefs of several others) that "have it appear the way the originator intended" is not a realistic goal.
(3) Mark wrote, in part....
"...to safely allow the creation of #1, which has historically been a concern; John L could probably do it in his sleep"
With no disrespect to John, this actually illustrates part of the problem I was trying to identify.
Certainly I could do it in my sleep (and, if they are familiar enough with some of the subtle details of SMTP, Joseph or Jiankang probably could too). But what you would be getting is my /our interpretation of what the documents say based on our understanding and recollections of the working group's discussions and intent, not just what the documents say. That is good from some points of view and bad from others.
By contrast, John L was not very active in the EAI work during most of its duration. If he did it, in his sleep or otherwise, you would probably get something closer (if there is a difference) to what the documents actually say. That is an advantage in some respects, but note that there are outstanding errata against some of those documents, identifying places were they were not sufficiently clear.
Barry was more active during that work, but, again, differently involved. Were he to do a set of tests, I would expect them to fall somewhere between John L's set and my set, whatever "somewhere between" means.
Things are complicated somewhat by the observation that SMTP, and to a slightly lesser extent, the EAI/SMTPUTF8 specs were very much influenced, and written with knowledge of, what is often referred to as the Postel Principle. That makes experience and judgment much more important than simply reading specifications as a Protocol Lawyer might (not that John, Joseph, Jiankang, Barry, or I would do that).
So, if John L does a test suite, you get his interpretation of what the standards say and what is important. If I were to do it, you would get my interpretation. Because our experiences, as well as our exposure to the development process for the protocols, are different, you would almost certainly get different tests, testing different things. That may be fine at least as long as you make it clear that what is being tested is UA's expectations or a set of expectations UA is signing off on, not tests of compliance to the standard.
john
-- Barry -- Barry Leiba (barryleiba@computer.org) https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Finternetmess...