[UA-discuss] Wanted: Some thoughts on measuring EAI

Wed Apr 20 14:06:27 UTC 2016

My first time speaking up here but global readiness validation is one of the areas I’m familiar with from a self-certification process.

Below is what I’d expect a company to do for self-certification and I believe that could be done via a bot model.

inline

From: Mark Svancarek [mailto:marksv at microsoft.com]
Sent: Tuesday, April 19, 2016 11:23 AM
To: Abdeslam NASRI <abdeslam.nasri at gmail.com>; Don Hollander <don.hollander at icann.org>; UA-discuss at icann.org
Subject: Re: [UA-discuss] Wanted: Some thoughts on measuring EAI

I was thinking about the following levels of EAI support.  We can assign each a different weighting dependent on importance of scenario (which is a judgment call we must make up front), and measure support levels by how many points a client, server or service gets.

Technical Support (clients)
Can send to an EAI address
Can send to an IDN-style email address
Can receive from an EAI address
Can receive from an IDN-style email address
Can associate EAI and IDN-style addresses as the same account for searching and sorting purposes

For typical productivity application testing, you need to cover a full a matrix along the lines of:

Send

Recieve

Email name is non- ASCII /domain is ASCII

Email name is ASCII /domain is non- ASCII

Email and domain are both non-ASCII

To/Cc a collection of email address with a mixture of formats – single From format as all ASCII

To/Cc a collection of email address with a mixture of formats – single From format as non-ASCII

To a single ASCII format and from a simple ASCII format with Cc of a collection of email address with a mixture of formats

At the very least, products could self-certify for these. The last one is, of course, the most tricky as the client may try to do a “simple” path logic if the To address is all ASCII.

For full evaluation, you’d need to test across the various hosting services to confirm and end-to-end story. A bot could handle monitoring these.

Then I’d see the following features for grouping:

·         Can group by equivalent ASCII and non-ASCII domain names

·         Can alias ASCII and non-ASCII email name when at same domain name
I actually would expect these to be at the server/service level so repeating below.

Technical Support (servers and services)
Can receive mail sent to an EAI address and send it to a compliant client
Can receive mail sent to an IDN-style email address and send it to a compliant client

For testing servers providing productivity interaction, it would be great to identify these as a matrix along the lines of:

Auto-generated alerts can send to

Replies for approving system tasks can be processed from

“Pass-along Messages” can be received from this format

“Pass-along Messages” can be sent to format

“Pass-along Messages” can be set to choose between alias format depending upon client

Email name is non- ASCII /domain is ASCII

Email name is ASCII /domain is non- ASCII

Email and domain are both non-ASCII

Admin can:

·         Group by equivalent ASCII and non-ASCII domain names

·         Alias ASCII and non-ASCII email name when at same domain name

User can configure their account to:

·         Alias ASCII and non-ASCII email name when at same domain name

·         Alias various combinations of ASCII and non-ASSII email names (even at separate domains)

Measuring and Monitoring Support
Can track the number of EAI accounts supported by each provider (e.g.. Coremail has ~50K; SaudiNIC is “negligible”; 163 is still at 0, etc.) as they are offered and grow over time
Can track the number of incoming EAI messages being received over time per provider
Can track the number of incoming “IDN-style” messages being received over time per provider

From: ua-discuss-bounces at icann.org<mailto:ua-discuss-bounces at icann.org> [mailto:ua-discuss-bounces at icann.org] On Behalf Of Abdeslam NASRI
Sent: Wednesday, April 13, 2016 11:51 PM
To: Don Hollander <don.hollander at icann.org<mailto:don.hollander at icann.org>>; UA-discuss at icann.org<mailto:UA-discuss at icann.org>
Subject: Re: [UA-discuss] Wanted: Some thoughts on measuring EAI

Hello Don and All,

In some earlier discussion with an EURid report présenter I suggested that UASG can issue a kind of UA IDN and EAI certification levels that can be acquired by software vendors and community developers. A certification level is gained by a software (client app, server App or API) when a standardized Test Suite -automated or not- is passed successfully.

The Test Suite evolve over time as we keep discovering issues. Tests should go far beyond a few ping commands to protocol implementation level and optional functionalities.

This way, either ICANN or any organization can initiate the EAI-IDN-compliance-validation process.

Bests,
Abdeslam NASRI
________________________________
From: Don Hollander<mailto:don.hollander at icann.org>
Sent: ‎4/‎14/‎2016 1:08 AM
To: UA-discuss at icann.org<mailto:UA-discuss at icann.org>
Subject: [UA-discuss] Wanted:  Some thoughts on measuring EAI
One of the things I would like to do is measure the extent of EAI deployment today  (which is included in this year’s business plan and budget) and for each of the next few years.
I’d also like to get a measure of how different client and server applications are able to handle both EAI and IDNs, with ‘handle' being the ability to ACCEPT and DISPLAY the different permutations we’ve got in our UA Use Cases.
I think that there should be some automatable way of testing servers – perhaps sending an SMTPUTF8 Request and measuring the response.   But how do we identify the servers to query?   Is there a list somewhere?   Do we leverage the work of the Anti-Virus and Spam monitors?
Could we automate the client software evaluation or will this require an install and manual exercise and evaluation?
So, before we issue a Help Wanted request for email evaluation I would appreciate your thoughts on how we might do this evaluation.
 Thanks in advance.
Don

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-discuss/attachments/20160420/4001a803/attachment.html>