Having just skimmed X.225 thanks to OhMeadhbh (https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.22...) I think Graham is correct that we don't have anything similar to the OSI "session" layer in the stack you're talking about; although the ARPANET TELNET protocol does have a lot of the same functionality, there's nothing analogous in SSL+https+JSON+RPC. I'm guessing the same is true of the "presentation" layer, but I'm certainly open to hearing why you think otherwise, if you do.

Also, if you happen to be familiar with X.225 (or read it following my prompt above), I have some questions in https://news.ycombinator.com/item?id=41789004!

Graham makes a good argument that, although there are some promising analogies between the physical/data-link/network/transport layers and the PHY/MAC/IP/TCP layers of TCP/IP over Ethernet, the model is overall a very poor fit even at those layers; it's better to not try to decompose network stacks into a predetermined set of layers, because the actual set of layers used is variable depending on the application and the environment.

I can't claim to have BTDT, but I did get the T-shirt. That's how I learned them :)

It doesn't seem like a "take down" as much as a re-iteration of all the things IBM, DEC, GE and various Telcos did wrong when implementing OSI. I could reduce it to one sentence: "Everyone was so intent on monetizing their own networking implementation they never thought enough about interoperability."

That's sort of like saying "TCP" is a failure because everyone now uses SSH instead of TELNET. TCP/IP still has to do all of the things the OSI stack does, it just does it in a different manner and there are (thankfully) plenty of well defined wire-formats and processing expectations so interoperability is pretty straight-forward. But I still think IPSec would have been MUCH easier to deploy had TCP/IP maintained a rational distinction between presentation and session layers. I guess what we learned is that SSL/TLS and FreeSWAN's assumptions about routing encrypted payloads were "good enough."

Also, if you're going to compare TCP/IP to various OSI implementations, you should compare the full stack including PEM, MOSS, SMIME, SSL/TLS, SSH. Each muddies the difference between presentation and application layers, but as in the previous paragraph, no one seems to care. Talking SMTP over SSH (or SSL/TLS) is totally fine; you don't need to have a sub-protocol to define how a presentation layer on top of a secure session layer works if you can make certain assumptions about the behaviour of the code on the other side of the network connection.