4 ms·
Partly firewalls and proxies. If you've not read it already you might be interested in https://tools.ietf.org/rfc/rfc3205.txt https://tools.ietf.org/rfc/rfc3205
by Pete_D 7y ago
Partly firewalls and proxies. If you've not read it already you might be interested in https://tools.ietf.org/rfc/rfc3205.txt https://tools.ietf.org/rfc/rfc3205.txt ("On the use of HTTP as a Substrate"). I wish we still built protocols too.
- BlueTemplar 7y agoIndeed. IMHO the right move would be to put pressure on bad actors that only allow HTTP over port 80 and still claim to be "ISPs"... (And with IPv6 having been finalized, NATs are now obsolete.) 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-technological-approach-to-free-speech https://knightcolumbia.org/content/protocols-not-platforms-a...
- shadowgovt 7y agoNovel protocols have their uses, and when that use can be demonstrated they can find their niche. But their value has to be extremely high to justify the opportunity cost of using them over something more established. 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.
- BlueTemplar 7y agoWell, yes, lower level protocols are harder to implement and deploy because they require new hardware - but I'm not sure how are they relevant in a discussion about higher level protocols that are in software and build on the Internet Protocol?
- shadowgovt 7y agoThe details of the complexities change, but the complexities are still there. You still need adoption by multiple parties, you still need to solve the application level challenges that HTTP solves (including, most importantly, secure communication over an open network), and you still need tooling to understand the protocol in flight, including its failure modes, to debug an application built atop the protocol. And you lose the utility of libraries and infrastructure built around using the other protocol. 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.
- BlueTemplar 7y agoI can only be suspicious about too much complexity and stacking in what is essentially infrastructure - that should be reliable, and therefore have minimum complexity. Any initial opportunity costs are tiny when these protocols are used by billions of devices !
- shadowgovt 7y agoBut they aren't. The vast majority of novel protocols never see a billion adopters. There are a handful that have; the email protocols are one, HTTP is another. 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?
- BlueTemplar 7y ago