4/23/2026 at 12:31:57 PM
>> SMTP "“didn’t win because it was ‘better,’” he argued, but “just because it was easier to implement."Yes - and this is actually really important! It's true of most of the important early internet technologies. It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts, while internet standards let individual decentralized admins hook their sites together.
Did any of the ITU standards win? In the end, internet swallowed telephones and everything is now VOIP. I think the last of the X standards left is X509?
by pjc50
4/23/2026 at 1:15:32 PM
> It's the entire reason "internet" standards won over "telco" (in this case ITU) standards - the latter could only be deployed by big coordinated efforts,Anyone remember the promise of ATM networking in the 90's? It was telecom grade networking which used circuit switched networking that would handle voice, video and data down one pipe. Instead of carelessly flinging packets into the ether like an savage, you had a deterministic network of pipes. You called a computer as if it were a telephone (or maybe that was Datakit?) and ATM handed the user a byte stream like TCP. Imagine never needing an IP stack or setting traffic priority because the network already handles the QoS. Was it simple to deploy? No. Was it cheap? Nooohooohooohooo. Was Ethernet any of those? YES AND YES. ATM was superior but lost to the simpler and cheaper Ethernet which was pretty crappy in its early days (thinnet, thicknet, terminators, vampire taps, AUI, etc.) but good enough.
The funny part is this has the unintended consequences of needing to reinvent the wheel once you get to the point where you need telecom sized/like infrastructure. Ethernet had to adapt to deterministic real-time needs so various hacks and standards have been developed to paper over these deficiencies which is what TSN is - reinventing ATM's determinism. In addition we also now have OTN, yet another protocol to further paper over the various other protocols to mux everything down a big fat pipe to the other end which allows Ethernet (and IP/ATM/etc) to ride deterministically between data-centers.
by MisterTea
4/23/2026 at 1:20:53 PM
> Ethernet had to adapt to deterministic real-time needsWithout being able to get too into the telco detail, I think the lesson was that hard realtime is both much harder to achieve and not actually needed. People will happily chat over nondeterministic Zoom and Discord.
It's both psychological and slightly paradoxical. Once you let go of saying "the system MUST GUARANTEE this property", you get a much cheaper, better, more versatile and higher bandwidth system that ends up meeting the property anyway.
by pjc50
4/23/2026 at 1:52:25 PM
ATM was superior in the context of a bill-by-the-byte telco-style network where oversubscribed links could be carefully planned. The "impedance mismatch" IP's of unreliable datagram delivery with ATM's guaranteed cell delivery created situations where ATM switches could effectively need unlimited buffer RAM to make their delivery guarantees even if the cells were containing IP datagrams that could just be discarded with no ill consequences.There's likely an element of the "layering TCP on TCP" problem going on, too.
The classic popular treatment of the subject is: https://www.wired.com/1996/10/atm-3/
by EvanAnderson
4/23/2026 at 1:41:09 PM
Pretty sure TSN is unrelated to ATM determinism, and comes from a completely separate area (replacing custom field buses where timing and contention is more important than bandwidth). Some of ATM complexity came from wanting to deliver the same quality of experience as plesiosynchronous networks provided for voice (that's how it got the weird cell size).Once those requirements dropped down (partially because people just started to accept weird echo) the replacement became MPLS and whatever you can send IP over where Ethernet sometimes shows as package around the IP frame but has little relation to Ethernet otherwise.
by p_l
4/23/2026 at 3:37:54 PM
Not directly related but a consequence.by MisterTea
4/23/2026 at 7:55:06 PM
ATM semantics and TSN semantics are quite different, the closest overlap would be in AFDX (avionics full duplex ethernet) except AFDX creates static circuitsby p_l
4/23/2026 at 6:12:11 PM
I started my career at France Telecom's R&D lab in Caen, Normandy. They had their own home-grown X.400 email client, and even though they could have set up a SMTP server for free, they deliberately chose to MX to a paid SMTP to X.400 gateway out of OSI ideology.It was complete garbage.
Another lab of theirs proudly made a Winsock that would use ATM SVCs instead of TCP and proudly made a brochure extolling their achievement "Web protocol without having to use TCP". Because clearly it was TCP hindering adoption of the Web /s
The Bellhead vs. Nethead was a real thing back then. To paraphrase an old saying about IBM, Telcos think if they piss on something, it improves the flavor.
One of the jobs I had applied out of college was to lead Schengen's central police database (think stolen car reports, arrest warrants etc) which would federate national databases. For some unfathomable reason, they chose X.400 as messaging bus for that replication, and endured massive delays and cost overruns for that reason. I guess I dodged a bullet by not going there.
by fmajid
4/23/2026 at 2:36:52 PM
WebPKI is derived from X.509, but I don't think X.509 lives on anymore. X.500 was stripped down to form LDAP, which is still in very heavy use today. There's still some X.400 systems in existence. I think some of the early cellphone generations may have used the ITU standards in the physical layer?Of course, the biggest--and weirdest--success of the ITU standards is that the OSI model is still frequently the way networking stacks are described in educational materials, despite the fact that it bears no relation to how any of the networking stack was developed or is used. If you really dig into how the OSI model is supposed to work, one of the layers described only matters for teletypes--which were are a dying, if not dead, technology when the model was developed in the first place.
by jcranmer
4/23/2026 at 1:57:54 PM
I'll note that while X.509 certificates are deployed widely on the Internet, they are not deployed in the manner the ITU intended. There is no global X.500 directory and Distinguished Names are just opaque identifiers that are used to help find issuers during chain building. That hardly counts as a win for the ITU in my book.by agwa
4/23/2026 at 9:56:07 PM
Doh! Of course it was easier to implement. IETF wants a working open source implementation before standardising.Have you ever tried to implement an ITU standard from just reading the specs? It's hard. Firstly you have to spend a lot of money just to buy the specs. Then you find the spec is written by somebody who has a proprietary product, and is tiptoeing along a line that reveals enough information to keep the standards body happy (ie, has enough info to make it worthwhile to purchase the specification), and not revealing the secret sauce in their implementation.
I've done it, and it's an absolute nightmare. The IETF RFCs are a breath of fresh air in comparison. Not only can you read the source, there are example implementations!
And if you think that didn't lead to a better outcome, you're kidding yourself. The ITU process naturally leads to a small number of large engineering orgs publishing just enough information so they can interoperate, while keeping enough hidden so the investment discourages the rise of smaller competitors. The result is, even now I can (and do) run my own email server. If the overly complicated bureaucratic ITU standards had won the day, I'm sure email would have been run by a small number of CompuServe like rent seeking parasites for decades.
by rstuart4133
4/24/2026 at 1:59:08 AM
Given that general public uses social network services for electronic messaging today, and those don't even pretend they want to be interoperable, we've got parasites of a totally different class on top of the Internet infrastructure.by ogurechny
4/24/2026 at 8:20:12 AM
It's not so much that SMTP won, it's that X.400 lost because it suuuuucked. Anyone who's ever had to work with that piece of s*t, as opposed to rhapsodising over what it could theoretically do, can tell you stories about this. It made Microsoft Mail and Lotus Notes look good in comparison. Notes actually did X.400, so imagine Notes but even suckier.by pseudohadamard
4/23/2026 at 12:48:39 PM
And you could add any number of the big standards group-based standards that a great deal of blood, sweat, and tears were poured into. Not universally the case, but more true than false.by ghaff
4/23/2026 at 1:53:14 PM
As x509 goes. I doubt many could explain it off hand with BER, DER and others being subset to ASN.1 and other obscura.I’ve never been a fan
by SV_BubbleTime
4/23/2026 at 1:33:24 PM
The critical part of that quote "Like a car with no brakes or seatbelts."by pabs3
4/23/2026 at 2:31:36 PM
It doesn't seem to have worked out like that? You might as well say "like a car without a man walking in front of it with a red flag" https://en.wikipedia.org/wiki/Red_flag_traffic_lawsby pjc50
4/23/2026 at 1:44:00 PM
That's a partisan framing. Another framing could be that SMTP is the golf cart SMBs were asking for, not the car they were being sold.by bragr
4/23/2026 at 1:38:21 PM
A lot of the IETF standards winning was vendors avoiding work even when paid for.Another was NIH in considerable important places.
Yet another was that ITU standards promoted use of compilers generating serialization code from schema, and that required having that compiler. One common issue I found out from trying to rescue some old Unix OSI code was that the most popular option in use at many universities was apparently total crap.
In comparison, you could plop a grad student with telnet to experiment with SMTP. Nobody cared that it was shitty, because it was not supposed to be used long. And then nobody wanted to invest in better.
by p_l
4/23/2026 at 3:13:28 PM
Yes, the TCP/IP protocol stack beat the OSI protocol stack comprehensively, even down to four layers beating out seven unless you're so wedded to the Magic Number of Seven that you see Session as distinct from Application in the modern world, like how Newton was so wedded to seeing Seven Shades of Light in a spectrum he was sure to note indigo as distinct from violet in the rainbow.(Presentation and Session are currently taught in terms of CSS and cookies in HTML and HTTP, respectively. When the web stack became Officially Part of the Officiously Official Network Stack is quite beyond me, and rather implies that you must confound the Web and the Internet in order to get the Correct Layering.)
https://computer.rip/2021-03-27-the-actual-osi-model.html - The Actual OSI Model
> I have said before that I believe that teaching modern students the OSI model as an approach to networking is a fundamental mistake that makes the concepts less clear rather than more. The major reason for this is simple: the OSI model was prescriptive of a specific network stack designed alongside it, and that network stack is not the one we use today. In fact, the TCP/IP stack we use today was intentionally designed differently from the OSI model for practical reasons.
> The OSI model is not some "ideal" model of networking, it is not a "gold standard" or even a "useful reference." It's the architecture of a specific network stack that failed to gain significant real-world adoption.
by msla