[UA-EAI] [Ext] EAI Working group Archives

[Mark Svancarek]

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 at jck.com] 
Sent: Wednesday, November 8, 2017 12:00 PM
To: Barry Leiba <barryleiba at computer.org>; John R. Levine <johnl at iecc.com>
Cc: Mark Svancarek <marksv at microsoft.com>; Don Hollander <don.hollander at icann.org>; Joseph Yee <jyee at afilias.info>; HEALTH Yao <yaojk at cnnic.cn>; ua-eai at icann.org
Subject: Re: [Ext] EAI Working group Archives



--On Wednesday, November 8, 2017 22:41 +0400 Barry Leiba <barryleiba at 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