Subject: The ecosystem is moving

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 11 May 2016 14:55:53 +0200

A very interesting paper (I said "intesresting", I didn't say I
agree!) on open networks where independant nodes with independently
developed programs interoperate thanks to standards. The author claims
closed and centralized systemes are better, because they allow faster
evolution (he uses security as an example).

Many IETF cases mentioned (XMPP, IPv6, email...)

https://whispersystems.org/blog/the-ecosystem-is-moving/

---

From: "Hejianfei (Jeffrey)" <[email-masked]>
Date: Wed, 11 May 2016 15:06:35 +0000

Hi Stephane,

Thank you for sharing this information. This happens to be a topic that I have been considering for quite a while.
I agree on most of the observations in this paper, e.g. "once you federate your protocol, it becomes very difficult to make changes. And right now, at the application level, things that stand still don't fare very well in a world where the ecosystem is moving."
But I am also searching if there is different way to do federation in application world. 
Most of current federations at application level target specific applications, so many "semantics" in those applications are exposed to the peering/federating protocols/interfaces. Some people call it a " beads-on-a-string " architecture. It "naturally" results in the issue "hard to change". 
I am thinking if a "layered" architecture could be applied to the application world. The key point may be to define a function set, concise and sufficient for service innovations. The servers inside the federation implement these functions and turn a stable layer. The main goal is that to deploy new services, only the client software at the two ends need to be upgraded. 
No doubt that it is very challenging since unlike the connectivity, the services above connectivity are so various, it is questionable if it is feasible to define a stable layer conveying future service innovations. But I have an initial feeling that such a function set could probably be defined based on experience from file and database systems. But this idea is still at quite early stage...

Jeffrey 
  
-----邮件原件-----
发件人: ietf [mailto:[email-masked]] 代表 Stephane Bortzmeyer
发送时间: 2016年5月11日 20:56
收件人: [email-masked]
主题: The ecosystem is moving

A very interesting paper (I said "intesresting", I didn't say I
agree!) on open networks where independant nodes with independently developed programs interoperate thanks to standards. The author claims closed and centralized systemes are better, because they allow faster evolution (he uses security as an example).

---

From: Paul Wouters <[email-masked]>
Date: Thu, 12 May 2016 11:37:29 -0400

There was always compuserv. 

And it is sad for everyone that we now have OTR, axolotl, double ratcheting and "signal tm".

Moxie started with OTR, migrated it to ECC and fragmented the encrypted IM community. It seems that now he has made it worse due to IPR.

Sad,

Paul 

Sent from my iPhone

> On May 11, 2016, at 08:55, Stephane Bortzmeyer <[email-masked]> wrote:
>

---

From: Dave Cridland <[email-masked]>
Date: Fri, 13 May 2016 17:09:50 +0100

I scribbled a response to Moxie's blog post from the perspective of someone
heavily involved in XMPP here:
https://medium.com/@dwdbah/federation-privacy-and-user-experience-c158547f07f5

TL;DR: He has some valid points, but his conclusions are very self-serving.

On 12 May 2016 at 16:37, Paul Wouters <[email-masked]> wrote:

> Moxie started with OTR, migrated it to ECC and fragmented the encrypted IM
> community. It seems that now he has made it worse due to IPR.
>
> Sad,
>
> Paul
>
> Sent from my iPhone
>

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 May 2016 12:33:12 -0400

Moxie has never really been interested in the standards game. He just likes
doing code.

If we want this to be really open, we have to put our own proposal on the
table.

I am currently trying to do just that.

On Fri, May 13, 2016 at 12:09 PM, Dave Cridland <[email-masked]> wrote:

> I scribbled a response to Moxie's blog post from the perspective of
> someone heavily involved in XMPP here:
>> Moxie started with OTR, migrated it to ECC and fragmented the encrypted
>> IM community. It seems that now he has made it worse due to IPR.
>>
>> Sad,
>>
>> Paul
>>
>> Sent from my iPhone
>>

---

From: [email-masked] (Martin Rex)
Date: Fri, 13 May 2016 18:57:13 +0200 (CEST)

> I am currently trying to do just that.

IMO, Moxie points to a number of real problems, but I think his
conclusions about the causes are wrong.

The two most important things that engineers (professionals and amateurs)
get wrong are:
  - failure to provide smooth interop with installed base
  - failure to take usability into account, how does a novice
    user get started?

Jabber (which allegedly uses XMPP) is a royal PITA.
It is possible to participate IETF Meetings remotely via Jabber,
and the IETF operates a jabber server, but that crappy server
refuses to let you in (provide a login/user account for you).
How to get a user account to join?  Well that's a black magic art
that is explained nowhere (at leat this was the situation
a while ago and for more than a decade).

I got myself an "jabber account" somewhere else, but at some point,
I got a "warning" that I would soon no longer be able to login to
that account, because my client software didn't support TLS.

Well, getting a jabber client _with_ support for TLS turned out to
be another royal PITA, because it wasn't available for my old Linux
distro, and compiling it my self would have required to obtain and
compile at least three dozen other libs and toolkits it depends upon,
and what my existing Linux distro had was "too old".

I only wanted to join IETF meetings remotely, and they're public anyways,
so I was just fine without TLS and my old client, but the XMPP freaks
running this stuff seemed to be fiercly determined of breaking backwards
compatibility just for the fun of it, giving a shit about their users,
similar to the developers of the newer client software, which gave a shit
about compiling the client software on a 5 year old linux distro.

There things that WhatsApp achieved in a straightforward and
user friendly manner:

   - signing up as a new user is *EASY*

   - getting the newest of their client software for a 5+ year old
     Android (e.g. Android 4.1) is no more difficult that getting
     it for bleeding edge OS releases

   - Interoperability with installed base was not impaired when
     rolling out the encryption-enabled clients

For these three issues, Jabber is a complete and utter failure.

-Martin

---

From: Paul Wouters <[email-masked]>
Date: Fri, 13 May 2016 13:05:11 -0400 (EDT)

> conclusions about the causes are wrong.

I agree.

> and what my existing Linux distro had was "too old".

That must have been an epicly old server because I've been using pidgin
with TLS for many years.

> about compiling the client software on a 5 year old linux distro.

Not "just for the fun of it", but specifically for RFC-7258

>     rolling out the encryption-enabled clients

And a day after the announcement I tried this with a friend of mine. We
both updated Whatsapp, and we ended up with my client saying "chats are
now encrypted" and the other endpoint saying "chats are not encrypted,
the other end needs to upgrade". Two days later this problem
automagically solved itself without an app update on either end.

How could an end-to-end encryption fail in such a way? There is either
some really untrusted GUI code lying, or some server-based "trusted"
MITM happening here.

Paul

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2016 13:32:58 -0400

I have to agree with Martin's general conclusions here: using XMPP is
really hard, both as an end-user and as a provider.   I am able to get it
working about one out of every three IETFs.  The sticky wicket tends to be
finding a place that will both host my XMPP account _and_ interoperate with
the IETF's XMPP server.

Why doesn't the IETF just operate an XMPP server on which IETF participants
can get accounts?   Layer 9, or is it just really hard?

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 May 2016 10:56:40 -0700

On 5/13/2016 10:32 AM, Ted Lemon wrote:
> really hard, both as an end-user and as a provider.   I am able to get
> it working about one out of every three IETFs.  The sticky wicket tends
> to be finding a place that will both host my XMPP account _and_
> interoperate with the IETF's XMPP server.
>
> Why doesn't the IETF just operate an XMPP server on which IETF
> participants can get accounts?   Layer 9, or is it just really hard?

Yes, but...

The IETF is supposed to be about interoperability.  If XMPP has on-going 
utility problems with interoperability, the IETF should look for ways to 
fix them.

To date, we really only have two services that demonstrate open (ie, 
multi-administration) interoperability at Internet scale:  email and DNS.

After this many years, that's sad.

d/

-- 

   Dave Crocker
   Brandenburg InternetWorking
   bbiw.net

---

From: Alia Atlas <[email-masked]>
Date: Fri, 13 May 2016 13:59:56 -0400

BGP

---

From: Dave Cridland <[email-masked]>
Date: Fri, 13 May 2016 19:14:16 +0100

I agree.

>   - failure to take usability into account, how does a novice
I agree, though I dispute the fact that XMPP has failed on the first.

> and what my existing Linux distro had was "too old".
The XMPP community switched to recommending mandatory TLS as a whole just
under two years ago, in no small part due to the issues discussed at length
within the IETF.

This doesn't represent a protocol change but a deployment one, and we
switched after extensively examining the usage of existing, popular servers.

> about compiling the client software on a 5 year old linux distro.
I think "freak" is presumably some kind compliment I'm misunderstanding,
but I'm unaware of any XMPP client which doesn't support TLS. I might have
to get a t-shirt made up with "XMPP freak" on it, though.

>    - signing up as a new user is *EASY*
Yes, I agree that onboarding is difficult. We've made it more, not less, so
in recent years by trying to avoid a growing spam problem, and this has
hurt usability.

But onboarding is difficult with email, too.

>      it for bleeding edge OS releases
Conversations, Yaxim? Both available in Google Play, although I'm only
aware of Yaxim running back to 2.1; Conversations might require something
more modern.

>      rolling out the encryption-enabled clients
There's actually no way to upgrade a set of arbitrary clients to mandatory
channel encryption unless you only have one client and you control it
absolutely. This is one of the points Moxie was driving at, and he's quite
right in this.

That said, I think the XMPP community did pretty well - a series of four
test days spanning four months, with a large number of client and server
developers. I appreciate you were caught out by this; I'm afraid that's a
penalty of running an open source desktop that I share; sometimes you find
yourself having to compile your own software when you weren't expecting it.
But the vast, vast majority of users probably didn't even notice.

> For these three issues, Jabber is a complete and utter failure.

Thanks, and I appreciate your work too.

By the way, if there's someone from Google here, can you please kill the
broken XMPP system you're running which is causing vast user confusion.

Dave.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2016 14:20:00 -0400

> utility problems with interoperability, the IETF should look for ways to
Sure, but this isn't necessarily an interop problem.   As far as I can
tell, it's an operational problem: XMPP is not very popular, and there are
no good XMPP services anymore.   Used to be I could just use Google
Hangouts, but that stopped working last year.

> multi-administration) interoperability at Internet scale:  email and DNS.

TCP, IP, UDP, NFS, DHCP, TLS, SSH, FTP, HTTP, NNTP, SIP, ...

Granted, there are issues with SIP, but we actually have a lot of really
solid successes, not just SMTP, POP and DNS.

> After this many years, that's sad.

If it were true, it would be!   :)

---

From: Dave Cridland <[email-masked]>
Date: Fri, 13 May 2016 19:27:48 +0100

> utility problems with interoperability, the IETF should look for ways to
XMPP does not have ongoing problems with interop. Quite the opposite - the
community is extremely positively engaged with the standards process at the
XSF, and interoperability issues are detected fast, treated seriously, and
fixed quickly. If they occur due to specifications being unclear, the spec
is fixed.

Every server I'm aware of, with the exception of Google's XMPP S2S service
(still operating but fundamentally broken) has supported at least the
baseline of "XMPP" for years.

> multi-administration) interoperability at Internet scale:  email and DNS.
If we're talking user-level services, I think we can add XMPP. Honestly, I
think XMPP interops better than email does, from a purely technical
standpoint. Obviously email is hugely more popular, but it's become
something of a minefield to safely interop in.

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 May 2016 12:52:30 -0700

On 5/13/2016 11:20 AM, Ted Lemon wrote:
> On Fri, May 13, 2016 at 1:56 PM, Dave Crocker <[email-masked]

So, yes, I did intend my comment to be provocative and did suspect I was 
missing one or another service.  But I also messed up, by not making 
clear I was targeting open, /distributed/, /applications-level/ 
services. (And yes, for this kind of discussion, DNS is an application.)

That is, I meant the qualifying test to be that there often is casual 
interoperability across a /sequence/ of independent administrations, and 
use by a very large fraction of the Internet.

Alia's BGP reference was the biggest surprise -- thank you, Alia! -- 
because I think it /does/ qualify and it hadn't occurred to me.

The problem with all of the others cited above is that they aren't at 
used at scale or aren't really used with open, multi-hop 
interoperability.  Much of the list, above, is for lower-layer protocols.

FTP and HTTP are simple, single-hop client/server mechanisms.  The 
latter is, of course, widely used, but it's a one-hop service.  (In 
reality, of course, the web has all sorts of additional hops, if one 
looks at content distribution, and other mechanisms, but they are behind 
the scenes and under tight control.)

NNTP is a very nicely distributed service, but it is not used at scale.

As I understand SIP use, the multi-hop mechanisms are another example of 
tightly-control operational prior arrangement, behind the scenes.  So it 
might qualify for "at scale" (though it might not) but it's operation 
isn't sufficiently open -- ie, permitting /casual/ interoperation.

I'm a fan of xmpp/jabber, but it, too, simply hasn't attained sufficient 
'at scale' use.

Hence my slightly-modified claim that, other than email and DNS (and, 
yes, BGP), we have been strikingly unsuccessful at deploying new 
distributed application services and getting them to be successful at scale.

d/

-- 

   Dave Crocker

---

From: Phillip Hallam-Baker <[email-masked]>
Date: Fri, 13 May 2016 15:58:56 -0400

On Fri, May 13, 2016 at 3:52 PM, Dave Crocker <[email-masked]> wrote:

> missing one or another service.  But I also messed up, by not making clear
> I was targeting open, /distributed/, /applications-level/ services. (And
> yes, for this kind of discussion, DNS is an application.)
>
> The problem with all of the others cited above is that they aren't at used
> at scale or aren't really used with open, multi-hop interoperability.  Much
> of the list, above, is for lower-layer protocols.
>
> FTP and HTTP are simple, single-hop client/server mechanisms.  The latter
> is, of course, widely used, but it's a one-hop service.  (In reality, of
> course, the web has all sorts of additional hops, if one looks at content
> distribution, and other mechanisms, but they are behind the scenes and
> under tight control.)
>

And so will email when we fix it.

I don't think SMTP is a good model to follow. The core problem is that many
of the problems that should have been handled by support in the protocol
were implemented with ad hoc perl scripts performing store and forward.

So as a result mailing lists don't really work very well, security is
poorly integrated and there is an upper limit on message size.

The reason no other application meets Dave's criteria is that they are bad
criteria.

---

From: Ted Lemon <[email-masked]>
Date: Fri, 13 May 2016 15:59:17 -0400

Yes, we could certainly do better.   I think you are mistaken about the
worldwide web, though.  Not only is it an example of a distributed database
of massive scope, but the various additional hops to which you referred are
specified in detail in many cases, not just ad-hoc.

I wonder if the reason you are so bearish on the worldwide web is that it's
not a _clean_ distributed database.   It's quite messy.   But best is the
enemy of good enough, and the www is certainly that.

On Fri, May 13, 2016 at 3:52 PM, Dave Crocker <[email-masked]> wrote:

> might qualify for "at scale" (though it might not) but it's operation isn't
> sufficiently open -- ie, permitting /casual/ interoperation.
>
> Hence my slightly-modified claim that, other than email and DNS (and, yes,
> BGP), we have been strikingly unsuccessful at deploying new distributed
> application services and getting them to be successful at scale.
>
>
>
>
> d/
>
> --
>
>   Dave Crocker

---

From: "John Levine" <[email-masked]>
Date: 13 May 2016 20:51:09 -0000

>NNTP is a very nicely distributed service, but it is not used at scale.

Dunno what scale means here.  I looked at my news spool and there seem
to be only about 600 hosts swapping mail by nntp, but the large hosts
like Giganews and Eternal September have lots of clients using the
NNRP flavor of NNTP to read and post.

R's,
John

---

From: Dave Crocker <[email-masked]>
Date: Fri, 13 May 2016 13:58:38 -0700

On 5/13/2016 1:51 PM, John Levine wrote:
> Dunno what scale means here.

In a multi-billion-person Internet, if it isn't used by hundreds of 
millions, it isn't at scale.

There's nothing wrong with niche tools, but they are quite different 
from the tools that effectively work for everyone, everywhere.

d/
-- 

   Dave Crocker

---

From: Matthew Kerwin <[email-masked]>
Date: Sat, 14 May 2016 09:09:33 +1000

Every deployment decision about HTTP for the past number of years is
predicated on the fact that there is a heap of middleware out there
(gateways, filters, caches, other proxies) that will break; not just
CDN-level stuff, but every toolshed IT Admin of every institution-level
setup seems go configure their own proxy. Even HTTPS isn't immune now, it
would seem. And these middle boxes are no more "behind the scenes" from an
end-user's POV than other protocols' relays or proxies. "Tight control" is
not a phrase I'd use to describe the situation.

Cheers,
Matty

---

From: Miles Fidelman <[email-masked]>
Date: Fri, 13 May 2016 21:38:57 -0400

Back to the original point, for a moment:

Stephane Bortzmeyer <[email-masked]> Wed, 11 May 2016 12:58 UTCShow 
header

> https://whispersystems.org/blog/the-ecosystem-is-moving/

My long-standing observation is that the climate has changed.  In the 
early days, there was both "demand pull" for new protocols, and an 
environment that encouraged (and to an extent) funded new protocol 
development and deployment.

Since then, the climate has changed:

- it's very hard to get a new protocol into the ecosystem (there are 
quite a few useful protocols, that simply are not supported)

- the drivers have changed from greater interconnection and 
interoperability (back to the original ARPANET drivers of resource 
sharing and collaboration) - to "can it be monetized?"

It's simply a lot easier to deploy a new SaaS, behind an API, and to 
charge for it, than it is to deploy new protocol infrastructure.

The exception seems to be when there is a strong "forcing function" - 
applied top-down.  DoD Force Transformation & the Command & Control 
Research Program drove new operational models into the military 
environment - into networks, into system specifications, and into 
doctrine.  Examples that come to mind:
- XMPP is widely used for tactical chat
- DIS is widely used to support distributed simulation and training - 
including deployment of persistent training federations
- Tactical Data Links (e.g., Link-16) are all over the place
- DDS is widely used for sensor-weapon linkages
Also of note - NNTP remains widely used on the SIPRNET, at the top of 
the MDMP (Military Decision Making Process)

Another example that comes to mind is the Digital Libraries Initiative - 
which forced a lot standards and protocols for library system 
interoperability.

IMHO, without such forcing functions, the natural tendency is toward 
centralized, proprietary services - and back toward a world of walled 
gardens.  Even in areas where we have a measure of widespread 
interoperability - such as calendaring - we see things like Google 
pulling iCal support - making it ever so much more tedious to schedule a 
meeting.

Miles Fidelman

-- 
In theory, there is no difference between theory and practice.
In practice, there is.  .... Yogi Berra

---

From: [email-masked]
Date: Sat, 14 May 2016 10:00:35 -0700 (PDT)

> baseline of "XMPP" for years.

Dave, all due respect, but this doesn't match my IETF experience, which lines
up with Martin's and Ted's pretty closely. Every time a meeting rolls around I
have to fight to get jabber chat working.

The BA meeting was better than usual. I fired up Psi, which despite being
crappy I am forced to use for work because Adium won't talk to the corporate
jabber server for some reason. Finding the two accounts I had set up previously
were both dead, I started the hunt for a functioning public server. (I tried a
private server once, but never succeeded in getting it going.)

After trying various server names from a list that obviously hadn't been
updated in years, I found one that responded but wouldn't configure properly in
Psi. So I switched to Adium, where it worked.

But the real test is whether or not you can join one of the IETF group chats. I
tried, and it worked. (My past experience has been that this has about a 50-50
shot of working, and when it doesn't work there's absolutely no indication of
what's wrong.)

So after maybe an hour of fiddling I once again had a working setup, albeit one
where I have to have use two different clients to connect to different servers.
As these things go, this counts as s significant success.

Now, I have no doubt that I'm missing some sooper seecret sauce, have bad
google-fu, should not be using a Mac because reasons, or whatever. But that's
beside the point. As abjectly incompetent as I undoubtedly am with jabber, I
doubt very very much that I rise to the level of incompetence of the average
user setting up IM for the first time.

And perhaps all these problems are not "interoperability issues", by your
definition of that term. But the bottom line is that the reasons why something
is a PITA don't change the fact that it's a PITA.

				Ned

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 May 2016 13:27:26 -0400

I suspect that a lot of these problems simply have to do with the fact that
Jabber isn't very mainstream, and so there are a lot of implementations out
there with not enough miles on them to have smoothed out some of the
significant interop problems.

---

From: "John Levine" <[email-masked]>
Date: 14 May 2016 19:24:11 -0000

>user setting up IM for the first time.

There certainly are a lot of IM clients, with a lot of them not
working very well.  I gave up on Adium, and now use Jitsi on my
Mac which has been quite reliable for what I do, including IETF
group chats.  My XMPP name is my Gmail address.

R's,
John

---

From: Richard Shockey <[email-masked]>
Date: Sat, 14 May 2016 16:58:00 -0400

— 
Richard Shockey
Shockey Consulting LLC
Chairman of the Board SIP Forum
www.shockey.us
www.sipforum.org
richard<at>shockey.us
Skype-Linkedin-Facebook rshockey101
PSTN +1 703-593-2683

>isn't sufficiently open -- ie, permitting /casual/ interoperation.

True Dave. There are a fair amount of constraints that have to be applied on a per hop basis but it does scale.   I would say dialing a phone number is pretty casual interoperation.. ☺ 

SIP URI as identifiers never took off [ yes Virginia Telephone numbers are still  here) but its use in core carrier networks along with the 3GPP IMS super set is now dominant.  In the US that is now about 40% of all Voice minutes in the interconnected Public SIP Telephone Network aka PSTN. With VoLTE it will be nearly 90%.

---

From: Richard Shockey <[email-masked]>
Date: Sat, 14 May 2016 17:46:23 -0400

In Line ..

— 

Richard Shockey

Shockey Consulting LLC

www.shockey.us

www.sipforum.org

richard<at>shockey.us

PSTN +1 703-593-2683

From: ietf <[email-masked]> on behalf of Miles Fidelman <[email-masked]>
Date: Friday, May 13, 2016 at 9:38 PM
To: <[email-masked]>
Subject: Re: The ecosystem is moving

Stephane Bortzmeyer <[email-masked]> Wed, 11 May 2016 12:58 UTCShow header

My long-standing observation is that the climate has changed.  In the early days, there was both "demand pull" for new protocols, and an environment that encouraged (and to an extent) funded new protocol development and deployment.

- it's very hard to get a new protocol into the ecosystem (there are quite a few useful protocols, that simply are not supported)

RS> Like security protocols?   Dare I say it its harder and harder to get any work done in standards bodies and the IETF in particular?   We have met the enemy and it is us… are we the new ITU?   That is another thread altogether. 

- the drivers have changed from greater interconnection and interoperability (back to the original ARPANET drivers of resource sharing and collaboration) - to "can it be monetized?"

RS> Duh! Time to market.  That said genuine interconnection and interoperability still does have value. Both the internet and the legacy as well as evolving global SIP voice network proves that.   There is a strong counter argument that long term value in global communications, namely persistent revenue streams, are built on globally interoperable services.  ATT, DT, BT, FT, Bell,  NTT etc have not gone out of business, though they endlessly whine about losing some of the value models.  We can send them some cheese to go with their whining. 

In the short term Layer 7 silos can work, especially in closed user communities, think instant messaging in the financial community and secure public safety applications as you correctly point out but at global scale you hit a wall eventually. 

It's simply a lot easier to deploy a new SaaS, behind an API, and to charge for it, than it is to deploy new protocol infrastructure.

RS> +1 That is certainly what is going on in Real-time Voice Services. Think Skype in its original deployment.  I noted that the piece called out the reuse of phone numbers as persistent global identifiers for service delivery.  Oh  Internet domains .. they are soooooo 90’s J  

I totally get that.  TN’s are globally unique they are ubiquitous, linguistically neutral and people have proven that if you use them correctly you can make a boat load of money.  WhatsApp?  Wow use the phone numbers and the existing national regulatory number allocation regime. Centralize your application ..collect 8 Billion dollars and do not pass GO.   Works for me!  Why didn’t I think of that?  

If I had 5 euro/dollars/pounds for every time I’ve heard “Phone numbers are stupid” I be sitting in the sun in St. Barts or the South of France with a cold glass of Champagne and would have resigned from this list years ago. 

The exception seems to be when there is a strong "forcing function" - applied top-down.  DoD Force Transformation & the Command & Control Research Program drove new operational models into the military environment - into networks, into system specifications, and into doctrine.  Examples that come to mind:
- XMPP is widely used for tactical chat
- DIS is widely used to support distributed simulation and training - including deployment of persistent training federations
- Tactical Data Links (e.g., Link-16) are all over the place
- DDS is widely used for sensor-weapon linkages
Also of note - NNTP remains widely used on the SIPRNET, at the top of the MDMP (Military Decision Making Process) 

Another example that comes to mind is the Digital Libraries Initiative - which forced a lot standards and protocols for library system interoperability.

IMHO, without such forcing functions, the natural tendency is toward centralized, proprietary services - and back toward a world of walled gardens.  Even in areas where we have a measure of widespread interoperability - such as calendaring - we see things like Google pulling iCal support - making it ever so much more tedious to schedule a meeting.

RS> Excellent observation and spot on with the issue with iCal.  Don’t get me started with trying to sync Outlook for Mac with the rest of my Apple device infrastructure.  Gurrrrr.  

Miles Fidelman

---

From: Miles Fidelman <[email-masked]>
Date: Sat, 14 May 2016 18:41:23 -0400

> In Line ..

Also in line.
>
> *From: *ietf <[email-masked]> on behalf of Miles Fidelman 
> <[email-masked]>
> *Date: *Friday, May 13, 2016 at 9:38 PM
> *To: *<[email-masked]>
> *Subject: *Re: The ecosystem is moving
>
> Stephane Bortzmeyer <[email-masked]> <mailto:[email-masked]> 
> Wed, 11 May 2016 12:58 UTCShow header
>
>
> RS> Like security protocols?   Dare I say it its harder and harder to 
> get any work done in standards bodies and the IETF in particular?   We 
> have met the enemy and it is us… are we the new ITU?   That is another 
> thread altogether.
>
>
>
> RS> Duh! Time to market.  That said genuine interconnection and 
> interoperability still does have value. Both the internet and the 
> legacy as well as evolving global SIP voice network proves that.   
> There is a strong counter argument that long term value in global 
> communications, namely persistent revenue streams, are built on 
> globally interoperable services.  ATT, DT, BT, FT, Bell,  NTT etc have 
> not gone out of business, though they endlessly whine about losing 
> some of the value models.  We can send them some cheese to go with 
> their whining.
>

Worse than that, I think.  The first generation protocols were not 
driven my market at all - think Ray Tomlinson and email, or Tim 
Berners-Lee and HTTP.  Nobody ever set out to make money from them - and 
nobody really has (except for some hosting).

> In the short term Layer 7 silos can work, especially in closed user 
> communities, think instant messaging in the financial community and 
> secure public safety applications as you correctly point out but at 
> global scale you hit a wall eventually.
>
> RS> +1 That is certainly what is going on in Real-time Voice Services. 
> Think Skype in its original deployment.  I noted that the piece called 
> out the reuse of phone numbers as persistent global identifiers for 
> service delivery.  Oh  Internet domains .. they are soooooo 90’s J
>
> I totally get that.  TN’s are globally unique they are ubiquitous, 
> linguistically neutral and people have proven that if you use them 
> correctly you can make a boat load of money.  WhatsApp?  Wow use the 
> phone numbers and the existing national regulatory number allocation 
> regime. Centralize your application ..collect 8 Billion dollars and do 
> not pass GO.   Works for me!  Why didn’t I think of that?
>
> If I had 5 euro/dollars/pounds for every time I’ve heard “Phone 
> numbers are stupid” I be sitting in the sun in St. Barts or the South 
> of France with a cold glass of Champagne and would have resigned from 
> this list years ago.
>
>
>
> Another example that comes to mind is the Digital Libraries Initiative 
> - which forced a lot standards and protocols for library system 
> interoperability.
>
> pulling iCal support - making it ever so much more tedious to schedule 
> a meeting.
>
> RS> Excellent observation and spot on with the issue with iCal.  Don’t 
> get me started with trying to sync Outlook for Mac with the rest of my 
> Apple device infrastructure.  Gurrrrr.
>

For what it's worth - I'm starting to push the idea of some kind of 
equivalent to the CCRP or Digital Libraries initiative - time for a new 
forcing function.

---

From: Dave Cridland <[email-masked]>
Date: Sun, 15 May 2016 00:43:39 +0100

> private server once, but never succeeded in getting it going.)

I'm intrigued as to what you're using as your corporate server, and what
prevents you using that to join IETF chatrooms.

> Psi. So I switched to Adium, where it worked.

Again, please let me know off list which server this is. The only thing I
can think of is if Psi is failing to use TLS, or cannot speak the available
sasl mechanisms. Possible, since XMPP had to move off digest md5 when that
became historic, and switched to scram, but maybe psi has been left behind
there. Possible that your corporate server has the same problems in
reverse, in which case it's probably also got major security holes running
throughout.

This probably does count as an interop issue in a sense, but I think is a
necessary one.

> shot of working, and when it doesn't work there's absolutely no
indication of

The IETF server, as I've mentioned, ran a self signed certificate for
years, after many services stopped peering with anything without a CA
signed certificate. It's fixed now, so should be considerably more reliable.

> user setting up IM for the first time.

Fair comment. On a Mac, you might try swift.im, too.

> is a PITA don't change the fact that it's a PITA.

Oh, I don't dispute that is a pain to find a server. Google doesn't help
here, since their server is at best crippled, and at worst breaks things
entirely. But XMPP does work for millions of people who use it, federated,
on a routine basis.

---

From: Nico Williams <[email-masked]>
Date: Thu, 19 May 2016 17:26:20 -0500

> evolution (he uses security as an example).

Propietary is better if you want a walled garden, but some day you find
yourself needing to let third parties use your service/protocol and
then... you have the same problem, only now you're the authority for the
documentation and so you have more responsibility.

Walled gardens end up having to let third parties in because people end
up needing integration with other systems.  Imagine that Glapchat has
enormous success and now businesses want to integrate it (including
additional security functionality, no doubt) into their enterprise
networks.  Glapchat can say "nö", but maybe Glapchat can monetize better
if they say "yes", but they might not be interested in making the
integration investment themselves.

As you can see, you can't really avoid standardization.  You can choose
SDO venues that have the attributes that you want (e.g., pay to play),
or even create your own SDO, or act as an unofficial SDO.  But you can't
really avoid standardization unless you start as a walled garden and
stay a walled garden with no third parties in your midst.

My advice to anyone creating a protocol is to first get running code,
then think about what SDO style you want, and then what SDO, and when to
start the standardization effort.  Some have brought their protocols to
OASIS, others to IEEE, others to IETF, others have formed their own
consortia, and others follow a very informal process until it no longer
works -- these are all perfectly valid choices.  But first, get running
code, otherwise you'll get bogged down and you'll then probably blame
anyone but yourself.

Nico
--