Subject: Re: [EAI] [IETF] Content Issues [

From: Shawn Steele <[email-masked]>
Date: Sun, 16 Oct 2016 01:00:33 +0000

> Seriously, at least in the near term, I'd oppose letting anyone post to an IETF list from a non-ASCII address.  This has been discussed before in other contexts, but it is important that we, as a standards body, be able to identify who is posting to our lists and trying to influence outcomes. 

I'm confused because I don't see how EAI addresses would be less accountable than ASCII addresses.  Sure, they might be less readable, but surely people could have [email-masked] and we'd have no clue who they "really" were.

I'd vote for "eat our own dogfood"

-Shawn

---

From: Yuriy Kargapolov <[email-masked]>
Date: Sun, 16 Oct 2016 13:26:53 +0300

>> Seriously, at least in the near term, I'd oppose letting anyone post to an IETF list from a non-ASCII address.  This has been discussed before in other contexts, but it is important that we, as a…
Anyone?
Let's  start  from  Administrators  of  IDN ccTLD/gTLD (admin-c or/and
tech-c by IANA DB). They are "anyone"?

> I'm confused because I don't see how EAI addresses would be less
> accountable than ASCII addresses.  Sure, they might be less
> readable, but surely people could have
> [email-masked] and we'd have no clue who they "really" were.

> -Shawn

Excuse  me, from point of view man with English as mother-language you are right on 100%
But  some other picture will be from man with, for example, Swahili or
Russian or Kyrgyz or Bulgarian ... - so much other mother-languages are exist on Earth
Maybe I mistake or I didn't correctly understood you

> _______________________________________________
> IMA mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ima

-- 

Best Regards,
Yuri                      mailto:[email-masked]

---

From: [email-masked]
Date: Sun, 16 Oct 2016 06:48:12 -0700 (PDT)

> > Seriously, at least in the near term, I'd oppose letting anyone post to an
> > IETF list from a non-ASCII address.  This has been discussed before in other
> > contexts, but it is important that we, as a standards body, be able to identify
> > who is posting to our lists and trying to influence outcomes.

> I'm confused because I don't see how EAI addresses would be less accountable
> than ASCII addresses.  Sure, they might be less readable, but surely people
> could have [email-masked] and we'd have no clue who they
> "really" were.

You're missing the point. If I send to an IETF list from an EAI address, the
message I send is going to be an EAI message. Given the way EAI works, that
message is only going to reach the (currently small) subset of list
participants for whom the path to their eyeballs is EAI-capable at every step
along the way.

The effect of this is to essentially to create a EAI-capable subset of any
discussion. That breaks accontability, as John notes. But perhaps more
important is the fact that it also breaks the entire open model.

> I'd vote for "eat our own dogfood"

Like it or not, that's not possible at this point. Perhaps that will change at
some point in the future when the penetration of EAI has increased, but until
it does the best we could offer is to allow EAI addresses to receive the list
but not post to the list. And I don't think that's of sufficient utility 
to bother implementing.

				Ned

---

From: Shawn Steele <[email-masked]>
Date: Sun, 16 Oct 2016 15:39:54 +0000

I suppose it might depend on how it is configured?  I suppose the on-behalf-of or whatever could be tricky, but it is already munging the message.  So maybe it could just ignore the sender info?

Certainly there isn't anything blocking the digest version?

-----Original Message-----
From: Ned Freed [mailto:[email-masked]] 
Sent: Sunday, October 16, 2016 6:48 AM
To: Shawn Steele <[email-masked]>
Cc: [email-masked]
Subject: Re: [EAI] [IETF] Content Issues [

> > Seriously, at least in the near term, I'd oppose letting anyone post 
> > to an IETF list from a non-ASCII address.  This has been discussed 
> > before in other contexts, but it is important that we, as a 
> > standards body, be able to identify who is posting to our lists and trying to influence outcomes.

> accountable than ASCII addresses.  Sure, they might be less readable, 
> but surely people could have [email-masked] and we'd 
> have no clue who they "really" were.

You're missing the point. If I send to an IETF list from an EAI address, the message I send is going to be an EAI message. Given the way EAI works, that message is only going to reach the (currently small) subset of list participants for whom the path to their eyeballs is EAI-capable at every step along the way.

The effect of this is to essentially to create a EAI-capable subset of any discussion. That breaks accontability, as John notes. But perhaps more important is the fact that it also breaks the entire open model.

> I'd vote for "eat our own dogfood"

Like it or not, that's not possible at this point. Perhaps that will change at some point in the future when the penetration of EAI has increased, but until it does the best we could offer is to allow EAI addresses to receive the list but not post to the list. And I don't think that's of sufficient utility to bother implementing.

				Ned

---

From: Shawn Steele <[email-masked]>
Date: Sun, 16 Oct 2016 15:41:30 +0000

> Excuse  me, from point of view man with English as mother-language you are right on 100% But  some other picture will be from man with, for example, Swahili or Russian or Kyrgyz or Bulgarian ... - so much other mother-languages are exist on Earth Maybe I mistake or I didn't correctly understood you

People could already send content in non-English languages if they desired.  So the problem is "only" the address?

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Oct 2016 12:55:47 -0400

--On Sunday, October 16, 2016 6:48 AM -0700 [email-masked]
wrote:

>... 
> You're missing the point. If I send to an IETF list from an
> EAI address, the message I send is going to be an EAI message.
> Given the way EAI works, that message is only going to reach
> the (currently small) subset of list participants for whom the
> path to their eyeballs is EAI-capable at every step along the
> way.
> 
> The effect of this is to essentially to create a EAI-capable
> subset of any discussion. That breaks accontability, as John
> notes. But perhaps more important is the fact that it also
> breaks the entire open model.
> 
> Like it or not, that's not possible at this point. Perhaps
> that will change at some point in the future when the
> penetration of EAI has increased, but until it does the best
> we could offer is to allow EAI addresses to receive the list
> but not post to the list. And I don't think that's of
> sufficient utility  to bother implementing.
> 
> 				Ned

Ned,

Yes, exactly.  Even for the "receive but don't post" case, it is
worth remembering that just including a cc to a non-ASCII
address on a message, even if the sender and list addresses are
all-ASCII, or having non-ASCII in the headers when all addresses
are in ASCII, is sufficient to prevent many members of the
community from receiving the message.  I haven't thought through
the implications of IMAP-accessible archives of messages that
require SMTPUTF8 capabilities, but I don't think that would be
pleasant either.

FWIW, in the IETF context, those who are concerned about not
being able to use non-ASCII addresses because the local parts
cannot properly represent their personal names should probably
be pushing much harder on more substantive issues like why the
IETF does not allow list postings in their preferred languages
and provide (and insist on) real-time parallel translation at
meetings for all of the languages  whose users might be present.
Those are important, substantive, issues and not resolving them
prevents the community to be as diverse and open as it might
otherwise be.  Mailbox names are just identifiers.  I'd probably
feel differently if we had no provision for what were
historically often called "personal name phrases".  But those
arrangements have existed ever since we discovered that being
able to associate personal names with serially-assigned account
identifiers was useful (e.g., knowing me as "M3418" was never
helpful and was hard on transparency).  The required
functionality goes back to at least RFC 822 (and IIR earlier)
and has been possible with encoded words (which are widely
supported) since MIME was introduced 24 years ago.

   john

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Oct 2016 13:24:23 -0400

--On Sunday, October 16, 2016 3:39 PM +0000 Shawn Steele
<[email-masked]> wrote:

> I suppose it might depend on how it is configured?  I suppose
> the on-behalf-of or whatever could be tricky, but it is
> already munging the message.  So maybe it could just ignore
> the sender info?
> 

As long as the digest version does not contain non-ASCII
headers.  Remembering that the EAI specs encourage getting rid
of encoded words in favor of Unicode in UTF-8 in the headers,
the digesting mechanism would have to be able to translate
non-ASCII header information back.  That is certainly feasible
but I'm not sure it ought to be our highest priority.  

The tools needed to do could be part of another issue that
affects broad deployment of SMTPUTF8 address and header
material.  Ned can check me on this, but I think our assumption
when MIME was being developed was that, when a message was being
forwarded and had non-trivial structure or a charset parameter
different from that of the person/MUA doing the forwarding, the
norm, perhaps the norm for most forwarded messages, would be
encapsulation of the original message.  As things have worked
out, sometimes we do that and sometime we just include the
forwarded message inline (I can't guess which approach is in the
majority).  If I have an fully-SMTPUTF8-capable environment,
receive a message that requires non-ASCII header and address
handling, and want to forward that message to a colleagues whose
systems are less capable, I'm going to have to either fully
encapsulate the original message and any relevant header
material or I have a downgrading problem.  That problem is
closely related to the issues discussed in RFC 6857 and 6858,
but the POP and IMAP cases can assume some level of cooperation
and choice about client-server pairs and configuration.  The
forwarding case generally cannot.

Harish and Nalini, many of these issues were discussed at length
(on the list, in meetings (IETF and the workshops), and in the
halls) during and after the development of the EAI specs.
Except for some asides in RFC 6530 and elsewhere, the material
has not been written down.  As I think about this discussion, I
think a great first step in what you are trying to accomplish
would be to try to simply draw this material together into an
Informational document that discusses barriers and impediments
to deployment.  It seems to me that your current draft goes
several steps beyond that and toward best practices.  In that
context, some of my complaints and quibbling about technical
details are premature and a result of there not being an
adequate foundation.

best,
   john

---

From: Shawn Steele <[email-masked]>
Date: Sun, 16 Oct 2016 18:04:01 +0000

> It seems to me that your current draft goes several steps beyond that and toward best practices. 

You seem to have segued from my reply to the draft being discussed, so "your" appears to have changed meaning from the beginning to the end of the paragraph ;-)

-Shawn

---

From: John C Klensin <[email-masked]>
Date: Sun, 16 Oct 2016 14:38:18 -0400

--On Sunday, October 16, 2016 6:04 PM +0000 Shawn Steele
<[email-masked]> wrote:

> You seem to have segued from my reply to the draft being
> discussed, so "your" appears to have changed meaning from the
> beginning to the end of the paragraph ;-)

Yes, it probably did.   "your" (actually both times) in the
paragraph you quote above was intended primarily for Harish and
Nalini as I indicated at the beginning rather than you (Shawn)
or anyone else specific.   Sorry for the confusion.  

Of course, I assume they would be happy to have help from you,
Ned, Yuriy, or anyone else on this list.

best,
    john

---

From: [email-masked]
Date: Sun, 16 Oct 2016 11:28:18 -0700 (PDT)

> I suppose it might depend on how it is configured?  I suppose the
> on-behalf-of or whatever could be tricky, but it is already munging the
> message.  So maybe it could just ignore the sender info?

Which makes it impossible to properly identify, or contact, the person who
sent the message. And accountability goes out the window.

> Certainly there isn't anything blocking the digest version?

First, most active partcipants don't use digests, so even if this worked it
creates another subsetting, which is unacceptable.

Second, it doesn't actually work. To the extent digests recreate the semantics
of the original set of messages, they recreate the problems the original
messages had. Explode the digest and you're back where you started.

				Ned

---

From: <[email-masked]>
Date: Sun, 16 Oct 2016 20:01:30 +0000 (UTC)

John,

>adequate foundation.

I like the idea of a "Barriers to Deployment" document very much.   

I have also been following the discussion of the subscription to email lists.   I think that joining such lists is one of the important uses of email addresses.  I was just talking this morning to one of the not-very-computer-literate older ladies in the neighborhood and she was telling me about how useful she found the neighborhood email group to be.  So, I can see that this is something many people (not just IETFers!) probably find useful.

Harish & I will put our heads together and put together some bullet points on the potential "Barriers to Deployment" draft and then come back to the list for comments on major issues to be covered.

Meanwhile, Harish is trying to get in touch with Don at the UASG group.

I will also ask some of the other people from Latin America / Africa who may be interested in this topic to join the IMA email list.

We want to schedule a Bar BoF to discuss these topics in Seoul.  I am thinking Thursday morning breakfast meeting.   Maybe people can respond to me / Harish privately to let us know if there are conflicts.   The title of the Bar BoF will be "Deployment Issues for IDN / IEA".   This way, we can start working on at least consolidating the problems.  Then, work quietly to resolve them.

Thoughts? 
Thanks,

Nalini Elkins (for Nalini & Harish)
Inside Products, Inc.
www.insidethestack.com
(831) 659-8360

________________________________
From: John C Klensin <[email-masked]>
To: Shawn Steele <[email-masked]> 
Cc: [email-masked]
Sent: Sunday, October 16, 2016 10:24 AM
Subject: Re: [EAI] [IETF] Content Issues [

best,
   john

---

From: [email-masked]
Date: Sun, 16 Oct 2016 11:35:33 -0700 (PDT)

> > Excuse  me, from point of view man with English as mother-language you are
> > right on 100% But  some other picture will be from man with, for example,
> > Swahili or Russian or Kyrgyz or Bulgarian ... - so much other mother-languages
> > are exist on Earth Maybe I mistake or I didn't correctly understood you

> So the problem is "only" the address?

Someone can post in French or Spanish or even Myaamia or Mingo, but good luck
getting people to read it. Which means you can do it but it isn't supported in
any meaningful sense.

The impediments to actually supporting posting to an IETF list in languages
other than technical English are very real, but for the most part
non-technical.

The IETF could, if it so desired, adopt a multilingual approach similar to that
used in some other standards bodies, where a specific set of languages are
supported and translation is done on an as-needed basis.

Heck, the IETF could even go "full United Nations" and support a huge range
of languages - in theory at least.

The problem with all this is cost. Even when done really well - and doing this
stuff well is extraordinarily difficult - the burden on participants in terms
of translation delays, misunderstandings, and so on is very high. So much so
that the IETF as we know it would likely cease to exist.

And that's ignoring actual cost, which would be huge. And the money to pay for
it would have to come from somewhere. The way other organizations do it always
includes some element of "pay for play". And that, again, would change the
IETF into something unrecognizable.

The bottom line is right now the cost of participation in the IETF is being
able to read and write technical English to a reasonable degree plus access to
basic Internet email service. Replacing that one language with a list is almost
certainly going to add some kind of additional cost to the equation.

I don't think this is a good tradeoff.

Bringing this back to the original issue of being able to use an EAI address on
IETF lists, if you want that to work and not break our current model for
participation and accountability you're going to have to require that everyone
use an EAI-capable account and user agent. Even if you could get IETF
participants to do that - and I can assure you that pigs will fly first - 
think about the added cost of participation that brings.

I don't think this is a good tradeoff either.

				Ned

---

From: John C Klensin <[email-masked]>
Date: Mon, 17 Oct 2016 00:22:54 -0400

--On Sunday, October 16, 2016 20:01 +0000
[email-masked] wrote:

>...
> I have also been following the discussion of the subscription
> to email lists.   I think that joining such lists is one of
> the important uses of email addresses.  I was just talking
> this morning to one of the not-very-computer-literate older
> ladies in the neighborhood and she was telling me about how
> useful she found the neighborhood email group to be.  So, I
> can see that this is something many people (not just IETFers!)
> probably find useful.

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.  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.   If everyone within a particular community is using
non-ASCII addresses, typically addresses based on the same
language and script, all of the very hard problems about how to
design, e.g., globally-adapted MUAs that are localized to the
language and culture of particular communities (not just the
right script) essentially go away and having to get everyone to
upgrade to make a given list with non-ASCII addresses work
disappear or become much more focused.

> Harish & I will put our heads together and put together some
> bullet points on the potential "Barriers to Deployment" draft
> and then come back to the list for comments on major issues to
> be covered.
> 
> I will also ask some of the other people from Latin America /
> Africa who may be interested in this topic to join the IMA
> email list.

Excellent.

> We want to schedule a Bar BoF to discuss these topics in
> Seoul.  I am thinking Thursday morning breakfast meeting.
> Maybe people can respond to me / Harish privately to let us
> know if there are conflicts.   The title of the Bar BoF will
> be "Deployment Issues for IDN / IEA".   This way, we can start
> working on at least consolidating the problems.  Then, work
> quietly to resolve them.
> 
> Thoughts? 

Note that some of the people who have been contributing to this
discussion rarely attend IETF meetings face to face these days.
So think about whether their involvement would be useful enough
for you to arrange for remote participation.

best,
    john

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 17 Oct 2016 18:11:03 +0900

Hello Ned,

> participants for whom the path to their eyeballs is EAI-capable at every step

In Shawn's defense, I have to admit that I also read John's email as 
saying "if somebody had a non-ASCII address, they would be less 
accountable" independent of the mailing list complications that he 
mentioned afterwards. I was already going to reply to John about this, 
but then I saw Shawn's mail.

> important is the fact that it also breaks the entire open model.

Well, the message would go to the mailing list archive, which should be 
enough for theoretical accountability and openness. But of course, a 
mailing list where contributions from some set of participants to some 
other set of participants regularly disappear in a black hole don't make 
much sense.

> but not post to the list. And I don't think that's of sufficient utility

For the moment, I agree.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 17 Oct 2016 18:16:57 +0900

Hello John,

> community from receiving the message.

Agreed, but the people subscribed on the mailing list don't appear in 
the headers of the mails sent out to others on the list, so that 
shouldn't be a problem.

> I haven't thought through

There may be a time where we have a few remaining people with old IMAP 
UAs that may have problems accessing the IETF's SMTPUTF8-capable IMAP 
servers (if there actually are such things). In these cases, these 
people may have to use the Web archives to check these mails.

But that time is definitely well in the future.

Regards,   Martin.

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 17 Oct 2016 18:21:45 +0900

Hello John, others,

> but I'm not sure it ought to be our highest priority.

I think this depends on the level at which the digest is processed by 
the recipient. I haven't used digests much, and when I used them, I 
always saw them just as a concatenation of the mails with the relevant 
headers. In that case, they are just plain text, and should work well 
with UTF-8.

Of course, for cases where digests are elaborate multipart constructs, 
and clients and users that want to act on these constructs, that's 
different. I'm not enough of an email expert to know how important this 
kind of use case is.

Regards,    Martin.

---

From: [email-masked]
Date: Mon, 17 Oct 2016 01:58:46 -0700 (PDT)

> 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.

> The other is
> 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.

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

				Ned

---

From: [email-masked]
Date: Mon, 17 Oct 2016 02:15:50 -0700 (PDT)

> enough for theoretical accountability and openness.

You're ignoring second order effects - the fact that only a subset of
subscribers will see such messages and thus have no chance to respond is both
intrinscly nontransparent as well as inimical to the accountability provided by
full and robust debate.

As for archives, unless you can produce evidence that a significant fraction of
people actually regularly review the archives to check for messages they might
have missed, I view them as irrelevant to the matter at hand.

> But of course, a

It's a lot more fundamental than that. See above.

				Ned

---

From: Martin J. Dürst <[email-masked]>
Date: Mon, 17 Oct 2016 18:28:35 +0900

Hello Ned,

> think about the added cost of participation that brings.

I think 'everyone' may be difficult, but something like 99% or 99.9% 
will eventually happen, just because for most kinds of software, it's 
easier to produce one version for use worldwide than to uselessly divide 
the market.

As for added cost of participation, upgrading something like gmail is 
essentially instantaneous and free, and upgrading something like 
Thunderbird requires only a click or two. As these types of applications 
these days form the bulk of MUAs, the overall/average costs for 
participation won't be too big.

Regards,   Martin.

---

From: John C Klensin <[email-masked]>
Date: Mon, 17 Oct 2016 10:16:19 -0400

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

> 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.

>> 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

---

From: [email-masked]
Date: Mon, 17 Oct 2016 15:17:30 -0700 (PDT)

> participation won't be too big.

If you actually think there's no cost to "upgrading" your mail provider,
changing the client you use, or even adding an additional provider and client
to your workflow, there's no point in further discussion.

				Ned

---

From: Martin J. Dürst <[email-masked]>
Date: Tue, 18 Oct 2016 17:52:21 +0900

Hello Ned,

> to your workflow, there's no point in further discussion.

I'm sorry, but I never said (nor intended to say) that changing your 
mail provider or the client you use, or adding one more of one or both 
of these, is easy or cheap.

What I tried to say is that for *most* participants, at *some point in 
time*, the upgrade will essentially be free and simple.

Regards,    Martin.