Internet History and IP/OSI Protocol Wars

I recently read up on parts of Internet history, about IP versus OSI etc. and the pros and cons of each approach.

It started with the ARPA group of people around Vint Cerf, Jon Postel in the Internetworking Group (INWG) working with informal memos and loosely traded RFCs, patchwork solutions, working code, starting with a local solution and growing it etc. instead of starting with an architecture, thinking it through, putting it all into standards, documenting it well, add testing procedures, how can products get certified etc.

This informal "IP on Everything" approach helped spur much innovation, gave freedom, but unfortunately also the freedom to make mistakes and the freedom to take freedom away (restrict freedoms). What a protocol chaos. And so many undocumented protocols.

On the other side, SOAP, Web Services, ISO and OSI were all efforts along the path of "settle for a common format, think it through well, standardize it, and publish it for the benefit of everyone".

But not everyone wanted to declare and document their message formats, talk to their competitors, wait for their competitors, be hindered by their competitors since in standardization even minute details are up for discussion and agreement needs to be achieved.

(Note, I do realize that comittees with competitors on the board were harsh, cost nerves, help grow white hairs, efforts take longer than a quick locally-developed but incompatible solution and not all is sunshine and rainbows down the alley of sitting down with the competition - if they even show up to the discussion table...)

And these digital internetworking rebels like Vint Cerf, Marshall T. Rose, Jon Postel etc. from the ARPA, DoD Internet, IP side of internetworking, wanted to have the agile way which allows fast innovation, but also brings headaches and much much duplication of work down the timeline, along with an easy way to exert silo and walled-garden dynamics.

And of course it is also easier for programmers to develop something from a first version, add something, change something, refine it, twist it, try something new, change parts etc. etc. but at some point the developed software should become mature and they think things more through and model its application messages, formats, requests and responses, entities before further coding is done - or at least when a first testbed has been finished and the application has somewhat stabilized.

Imagine if the OSI had won the "protocol wars" - it took longer to work out the standards, get something working etc. - but look at, for example the aspect of user authentication and authorization. ISO nation bodies in cooperation with national citizen registers handing out digital certificates for citizens who want to have a digital certificate issued for them ... do the official verifications "yes this is me" once, then simply select this certificate as "user identity" and log in to your favorite x (gambling, onlineshopping, betting etc.) website. Instantly logged-in, verification can be shortened to just asking for a second security factor (2FA) from your phone, SMS text message or so, because your identity has already been proven by the national registry - once and for all. Surely, some websites can simply allow anonymous login and the usual e-mail verification process etc. like we have it today. But, imagine what this single aspect would have saved in terms of developer time over several decades, how many apps and platforms could have simplified this aspect and we as customers could all cut down on this when making a new account on websites, onlineshops etc. pp.

When we want to plan a route, we go to the website of our favorite routplanner or install a mobile app, which supposedly offers us the "best experience" (along with ads, upsells and cross-sells) for us. Imagine that, they are sending us what they believe is the best way to consume their service, which is the complete application by web ("the Web is the application delivery platform") which is one of the most unefficient and brittle ways of developing and providing an application (as HTTP is a stateless protocol per se), and then does an API request in a provider-specific format resp. application protocol.

What if, instead, those guys who want to offer the best possible navigation and route planning services for their area or their public transport service union, sat down with a bunch of other such providers, they define a common API format, discuss that in a standards comittee, get it refined and registered with the ISO, and then provide their services based on that. Of course, they can require prior signup or payment via their own website, and can therefore charge per request. And we customers would have applications for PCs (Windows, Mac, Linux - universal apps exist) and one for Android, one for iPhone - which can talk to all of the service providers world-wide, which provide route planning in that standardized format.

That was the vision of the ISO and OSI people. That is the essence of the ISO in general - domain experts getting together to discuss and settle a decision on the best and/or most-acceptable solution for everyone, so that everyone involved benefits world-wide. That was also the vision of the Web Service people ("universal formats! finally data integration is near!").

Yet, data and service integration, still is the holy grail and the untapped potential of Information Technology.

How childish, that we still have on our phone x different dating apps, switch between x different messenger apps, between x different "social" networks, betweeen x different route planner apps, between x different apps for short text-message threads, x webpages for video sharing, x apps for whatever, and so on ... which all provide similar services in their category - how laughable. We should have 1 app per category, speaking the top 1 or 2 standardized formats and be done with it.

The data islands, data silos and walled gardens, the incompatibilities cost so much useless duplicated effort down the road. Define a common application protocol and format for Gai Pow, for gods sake, and move on! Otherwise every new provider adding a bit of innovation has to re-create the other 90% off-the-shelf parts of such a platform and features which everyone offers.

Also, power dynamics of competitors like Apple Maps, Bing Maps, Nokia Maps, Google Maps - or social media network X, Y and Z etc. dont want to provide a common API and be easily-replaceable - and this is one of the ugliest anti-motivators of human progress in our time. The ability to use market power to force closed proprietary spying apps and closed and little-documented data formats on customers. Prioritizing data collection and telemetry above providing best possible service, together in unison with the other compatible providers, to the customers.

Like a friend of mine said: "Dude, this way ... we will never build the Enterprise."

Back to Gemlog