by Michael S. Kaplan, published on 2013/10/08, original URI: http://blogs.msdn.com/b/michkap/archive/2013/10/08/10454553.aspx
Previous blogs in this series:
Now back in part 17, when I said
"But the IETF (the Internet Engineering Task Force) and a lot of people and companies..."
I was being a little sloppy in my language.
Because the IETF doesn't as a part of its charter pay a lot of attention to competitiveness in products, specifically. Their view has to be a bit wider than that.
So I ended up reaching out to John C. Klensin directly to get a more rigorous definition about why Coremail XT 3.0 and any product like it was so important.
After pointing out that he was giving his personal opinion, speaking only for himself and not for the IETF, summarized how he felt the issue should be considered:
Fully internationalized email, especially with the local parts of addresses in local characters, is going to be very important within communities where Latin script is unfamiliar or difficult to use. There has been great demand for the capability in some of those communities. That demand is an obvious consequence of the observation that most people use variations on their personal names or phrases in their languages as user names and hence in the non-domain parts of email addresses. At the same time, because the EAI extensions necessarily use real UTF-8 encoded characters in addresses and header fields rather than a backward compatibility-friendly encoding like IDNA, there is a potential compatibility problem if part of a community converts and uses native-character addresses and another part does not.Using the Coremail announcement as an example, if a significant number of people whose primary language is Chinese start sending out mail that shows Chinese-character email addresses, other users (Chinese and otherwise) won't be able to receive mail from them or send mail to them until their mail software (both user interfaces and transport) are upgraded to support EAI. That probably makes trying to sell systems into the Chinese market that are not EAI-capable a bad idea in the fairly near future. The same problem is likely to occur in other countries and language communities as the EAI capabilities start being deployed and heavily used.
Now I am not looking at Coremail XT 3.0's manuals (which are probably in Chinese in any case!), but I am pretty sure that they have fallback mechanisms of some sort so that they would not, for example, be able to send email to even people using Coremail XT 2.0, but clearly for the best experience you will need to support EAI. For EAI itself, as Wikipedia points out:
The basic EAI concepts involve exchanging mail in UTF-8. Though the original proposal included a downgrading mechanisms for legacy systems this has now been dropped.
People like Mark Davis of Google have pointed out all along that even though the standard didn't ultimately go down the road of trying to define the down-level experience does not force implementations to ignore the need to build products that can work with prior versions.
People interested in this area could start with the Wikipedia article and the discussions that led to them dropping the attempt to define how EAI components should talk to ones that don't support EAI. While I used to disagree almost violently with the opinion, I came to realize that they were right.
After all, it wasn't The Unicode Consortium's job to define how MSLU should work! 😏
I can't predict the future so I won't even try. But I do know that the next few years are going to be quite interesting!
referenced by