Re: [EAI] [IETF] Barriers to Deployment [ was: Content Issues]

[John C Klensin <[e-mail]>]

--On Monday, October 17, 2016 01:58 -0700 Ned Freed
<[e-mail]> wrote:

>> > ...
> 
>> Note that there are a couple of things that are very different
>> between a neighborhood email group and the IETF list.   One is
>> that the same requirements for transparency and accountability
>> typically do not apply, at least in the same way.
> 
> I think at this point in time this is really a matter of
> degree, not a brightline disctinction. At this point in time
> the level of support for EAI is sufficiently low that it makes
> use of EAI addresses on any nontrivial mailing list
> problematic.

Agreed.  I was projecting into the future and into communities
in which dominant email providers who do not fully support
SMTPUTF8 were not significant (see below).  If current trends
continue, we may never get there.  From my point of view, that
would be really sad but, like you, how happy or unhappy I am
does not seem to affect the trends.

>> The other is
>> closely related to what at least some of us have believed all
>> along would be the normal deployment model for SMTPUTF8, by
>> deployment within communities, particularly communities with a
>> small number of shared primary languages, who conclude that
>> they need it.
> 
> The problem is that communities increasingly no longer match
> up with email providers. The obvious example here is the
> ever-increasing concentration of email users on a
> ever-shrinking number of providers.
> 
> In theory this could make EAI deployment simpler, but in
> practice only one of the four in MAGY support EAI right now.

If that sentence was about full support, including mail
origination and IMAP and POP support for "foreign" clients, I'm
not sure the number would be as high as one.

> I'm not happy about any of this, but my lack of happiness
> doesn't change the situation any.

Yep.
And there lies a very difficult social and economic difficulty
with deploying the EAI protocols.  Especially for a very large
provider, support may be difficult to turn on (one may want a
flag day or flag second so that all of the pieces of one's
systems are either advertising support or not) and expensive to
support (imagine calls from people complaining about an
apparently fouled-up error message whose headers they can't read
or even the additional organizational/management requirements
when a question must be routed to someone who can understand
both the headers and addresses on a message and the language of
the body content).   As Martin pointed out, if the trend toward
use of email addresses as identifiers in other contexts
continues, support for non-ASCII addresses requires support, not
just in email, but in web forms and interfaces, in support for
X.509 and similar certificates and programs that utilize them,
and, in many countries, in assorted "fill in form" legal and
other documents (including in form-filling-out programs that
don't require real-time attachment to the Internet).   Against
those costs, the providers, many of whom see providing email as
a necessary adjunct to profitable services rather than as a
profit center, have to weigh the unhappiness of communities who
want to use non-ASCII addresses (but who manage to use ASCII
addresses in their complaints whether the content is in English
(or some other European language) or not) against those costs,
including the costs (both implementation and support) of
allowing non-ASCII email addresses in non-mail contexts.   In
addition, those who understand the issues are likely to see
risks from acquiring a bad reputation when things go wrong that
far outweigh the perceived goodwill from accommodating non-ASCII
addresses and headers.

There will be places where the economics work.   My assumption
is that the number of them will gradually rise.  However, in the
near term, the right conditions are likely to exist only in
areas (typically countries) in which virtually everyone in the
country uses the same writing system _and_ the dominant email
provider(s) draw the vast majority of their users / business
from that country rather than globally.   At least absent
government action of the form of "you are not going to do
business in this country unless..." (a type of move that it may
not be wise to encourage), that makes places like China and
Thailand much more likely candidates for critical mass
deployment than many other places.  Perhaps it is not a
coincidence that the two workshops were in those countries.  And
perhaps when they can report to the rest of the community about
problems encountered and how they were dealt with, the
perception of likely risks and costs will diminish.

We went down the SMTPUTF8 path to try to ensure interoperability
without really bad problems for users of both ASCII and
non-ASCII addresses when it became clear that, unless there was
an IETF standard for non-ASCII addresses, we'd see a number of
incompatible solutions with nasty issues at the boundaries.  I
don't regret that decision and think the result was fairly close
to the best that could be done.  However, we knew that it was
going to deploy only slowly and that there would be difficulties
until everyone had converted.  I don't think that suggests we
should stop trying and I've very encouraged by the intentions
and efforts of Nalini and Harish that started this thread.  I
just hope we can move forward with a clear separation of issues
(e.g., what requires, and is necessary for, non-ASCII content
versus what requires, and is necessary for, non-ASCII
addressing) and a minimum of hyperbole and false promises.  

I mention the latter only because there have been hints in this
discussion that the absence of non-ASCII email addresses are
_the_ barrier to deployment of the Internet to the next billion
(or some other number) people.  We've heard that before, first
with IDNs, than with top-level IDNs, and, more recently, with
non-ASCII email addresses.  There has been little evidence that
deployment of IDNs or top-level IDNs, no matter how worthwhile,
has made a significant difference to the deployment curve even
though there has been evidence that their absence was used as an
excuse for not deploying more infrastructure or reaching more
communities.  Let's avoid encouraging the perception that the
absence of EAI is yet another excuse to avoid Internet
deployment.

    best,
     john