[UA-EAI] Seeking two new terms, for (old-style email) and (UA-style email)

Wed Feb 3 05:43:32 UTC 2021

HiThis appears like a practical classification. I suggest &ldquoTraditional&rdquo for (old-style email and &ldquoUniversal&rdquo (UA-style email)

Warm Regards

Nitin Walia  
नितिन वालिया

Director   
निदेशक

Data Xgen Technologies  
डाटा एक्सजेन टेक्नोलॉजीज

Email: nitin at xgenplus.com 
नितिन@एक्सजेनप्लस.भारत

Web: www.xgenplus.com 
एक्सजेनप्लस.भारत

Mobile | whatsapp: +919828025000  |  Skype id - n_walia

From: Jim DeLaHunt   MailId : [110827392]To: uaeai Subject: [UA-EAI] Seeking two new terms, for (old-style email) and (UA-style email)Date: 02 Feb 2021 02:01:56 PM 
Email WG colleagues:
In our discussions, I feel that we are missing one term, and a second term is not satisfactory and not consistently used. I propose that we come up with better terms for both cases .
The first term is something that can refer to old-style email addresses and email messages and email software. "Old-style" means that email addresses are limited to an ASCII subset as defined in RFC 5822, or HTML5  regular expression. It also means that domain names are limited to letters, digits, and hyphens (LDH) characters, and traditional 3-character TLDs and 2-character ccTLDs. I will use __OLD__ as a placeholder for this term .
The second term is something that can refer to the kind of  email addresses and email messages and email software for which we want Universal Acceptance. It includes internationalised email addresses, and newly-registered TLDs, and internationalised domain names, and even LDH domain names longer than 3 characters. I will use __NEW__ as a placeholder for this term .
I believe we have no agreed-upon term for __OLD__ in our UASG writing.  Here are some of the phrases I have used to fill the role of __OLD__, and the weakness of each:

non-EAI (has no meaning unless you know the term "EAI")
Legacy (not clear, legacy relative to what?)
ASCII-only (not precise, because some ASCII characters e.g. "@" and " " aren`t permitted by RFC 5822, and new long TLDs are ASCII-only but not __OLD__) .

We have an agreed-on term for __NEW__, namely "EAI". But I am dissatisfied with this term, for the following reasons:

it is jargon, with no inherent meaning, so we have to explain what "EAI" means .
the acronym EAI has other common meanings: https://acronyms.thefreedictionary.com/EAI>, https://en.wikipedia.org/wiki/EAI>
Email Address Internationalisation refers only to addresses, but I argue __NEW__ should be a term we can apply to email messages and email-related software not just addresses .
Email Address Internationalisation refers to a change process which addresses went through and completed. I argue __NEW__ should be a  property of addresses and messages and software, which can go on forever. It should not imply a change process which must end .

So, I suggest we start trying to insert placeholders __OLD__ and __NEW__ when we talk about our "EAI" work, and try plugging various terms into those placeholders to see which ones work well .
I suggest that good terms will be fairly self-explanatory. They will imply that __NEW__ is better than __OLD__. They should permit direct translation into a number of languages and keep their meaning (or in the long term, we should come up with terms for __OLD__ and __NEW__ in all the languages in which we communicate).  These terms should work as adjectives and as nouns describing state (in English, at least). 
Note that "Universal Acceptance" is a pretty good term, by these measures. It is pretty self-explanatory. It sounds like a something good to have .

Here are some test sentences, to use for trying out new terms.  Can you come up with other good test sentences?
Part of Universal Acceptance is promoting __NEW__ email, and correcting __OLD__ email software. 
The __NEW__ Email Working Group is part of the UASG .
I got a .भारत (.bharat) email address as part of the promo on Republic Day of India. I am excited to try out __NEW__, but my mail client only accepts __OLD__ addresses .
Even an email address from a new, longer TLD like .MUSEUM, is no longer an __OLD__ address, it is a __NEW__ address .
Every email address from an internationalised domain name (IDN) is a __NEW__ address, even if the mailbox part follows the __OLD__ limits .
It doesn`t matter if all your email servers support __NEW__ email, if your spam filter only passes __OLD__ email, you can`t use __NEW__ addresses .

To get discussion started, here are some initial suggestions for terms. Are these better than what we have now? Can you come up with even better terms?
for __OLD__: "limited-Latin".   for __NEW__: "globally inclusive"
Trying them out: "Part of Universal Acceptance is promoting globally inclusive email, and correcting limited-Latin email software." "Even an email address from a new, longer TLD like .MUSEUM, is no longer a limited-Latin address, it is a globally inclusive address."
I will start using these terms in future EAI WG (sorry "Globally Inclusive Email WG") discussions, so that we can see how they feel. I look forward to your impressions and ideas .
Best regards,       &mdashJim DeLaHunt
-- 
.   --Jim DeLaHunt, jdlh at jdlh.com     http://blog.jdlh.com/ (http://jdlh.com/)
      multilingual websites consultant

      2201-1000 Beach Ave, Vancouver BC V6E 4M2, Canada
         Canada mobile +1-604-376-8953
_______________________________________________UA-EAI mailing listUA-EAI at icann.orghttps://mm.icann.org/mailman/listinfo/ua-eai_______________________________________________By submitting your personal data, you consent to the processing of your personal data for purposes of subscribing to this mailing list accordance with the ICANN Privacy Policy (https://www.icann.org/privacy/policy) and the website Terms of Service (https://www.icann.org/privacy/tos). You can visit the Mailman link above to change your membership status or configuration, including unsubscribing, setting digest-style delivery or disabling delivery altogether (e.g., for a vacation), and so on.Do not Remove:[HID]20210202140156225[-HID]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mm.icann.org/pipermail/ua-eai/attachments/20210203/22d40420/attachment.html>