It's not just text transfer... HTTP also goes hand-in-glove with HTTPS, which is a technology few people want to build an alternative for (and fewer people should be trusted to do correctly).
There's a very good reason that so many systems block everything except port 80. Does the idea of protocols instead of platforms address that reason? Because most people don't want to make themselves vulnerable to attacks along threat vectors they aren't even aware exist.
Elaborate? Rather than using different ports for different protocols and filtering what you don't want/need, you instead tunnel everything through port 80 and effectively don't filter at all?
HTTP has both elaborate tooling for deep packet analysis and a battle-hardened secured protocol, which we don't get with new protocols.
These days, don't you think that consumer routers sold without firewalls should be about as illegal as selling cars with only motor braking ?
And, as they say : > It would be useful to establish guidelines for "firewall-friendly" protocols, to make it easier for existing firewalls to be compatible with new protocols.
I believe that the Internet is fundamentally about protocols, and that platforms are to be banned if we care about it : https://knightcolumbia.org/content/protocols-not-platforms-a...
To turn the question sideways a bit, there's nothing stopping some conglomeration from developing an alternative to 802.11 standards. All they have to do is create the hardware, convince people to use the hardware, create software to adapt a novel protocol to the higher layers of the networking stack to make it usable by application software (including addressing all of the ways that a new lower layer inevitably breaks an abstraction or two), and create the tooling necessary to make an ecosystem of non-802.11 wireless devices easy to install, maintain, and interoperate.
... But outside of particular special applications where something about 802.11 protocols or the frequencies they communicate upon makes them an ill-fit, there aren't many reasons to do so. Good enough displaces perfect in the common case.
The opportunity cost to do that with a brand new protocol instead of taking advantage of HTTP's flexibility to build new protocol atop HTTP is high.
Nobody's stopping anyone from building new protocols... Except, of course, the fact that nobody wants to adopt a new protocol. But if someone does come up with an indispensable alternative to HTTP(s), it should find traction, right?
"Why use the HyperTEXT Transfer Protocol for things completely unrelated to text..."
If Google agrees with you, would we want to stop them?
It shouldn't be necessary to toss out the cookie jar, the HTTP connection handler, the XSS protection just because one wants to do something a bit different with the final rendering stage.