[p_l]

A lot of the textual nature of older IETF protocols, including the CR LF line endigns, can be probably traced to how easy it was to bang out a bad implementation full of subtle problems that could be debugged by sitting an undergrad student at a teletype instead of spending time on having some binary serializer (that telecom companies definitely had money for)

[JoshTriplett]

Yeah, a fair bit of email protocol reeks of "is this tolerant of `telnet mailserver 25` and whatever garbage that might produce".

[p_l]

A lot of old RFCs explicitly mention running on top of TELNET.

Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and one of the earliest ways to access ARPAnet outside of machines directly on it was through calling into a TIP which set up bidirectional stream from your modem to a port on some host.

[tbrownaw]

> Additionally, as much people like to harp about "telcos focusing on connection-oriented protocols while we ran loops around them with packets", the reality is that NCP and later TCP pretty much focused on emulating serial lines around, and

The idea with packets is that you don't need to reserve N bit/s of each link along the route to whatever system you're talking to; instead you just repeatedly say "here's a chunk of data, send it to X". It's not really relevant that the typical thing to do with these packets is to build a reliable stream on top of them, what matters is that everything except the endpoints can be a lot dumber.

[miki123211]

There's something in-between traditional (IP style) packets and traditional (TDM / ISDN style) circuit switching, where you use packets with no bandwidth guarantees, but address them by connection number, not endpoint address.

This still requires you to set up a connection beforehand, but doesn't require you to reserve resources you might not be using.

[p_l]

And while certain telcos had packet network focused on that (Bell and Datakit, for example), and generally OSI cared about including QoS indicators, CLNS and its specific on-the-wire implementation CLNP is so similar to IP that IPv9 explicitly called it out in the proposal to replace IPv4 with it (because of ISO 160bit addressing)

[cyberax]

It's also a reflection of the state-of-the-art at the time. Binary protocols were an unmitigated disaster, with standards bodies thinking that applying to the ISO for your organizational ID is a perfectly fine step that anyone does anyway.

[zzo38computer]

> with standards bodies thinking that applying to the ISO for your organizational ID is a perfectly fine step that anyone does anyway

Fortunately there is the 2.25 OID arc now, which you can use without any registration with anyone. There are also other ways to register OIDs for free. (I think that it is better than using domain names, which can be reassigned, and also require registration anyways. IDN is an even more severe problem (it could have been designed better, but they made it worse instead).)

I had idea (which would have to later be made standardized by ITU or ISO (preferably ITU)) of a new OID arc which allows you to combine an existing identifier (of many different types, such as: international telephone numbers, amateur radio call signs, internet domain names (encoded as bijective base 37), IP addresses, ICAO airport codes, etc) with a timestamp, and optional auto-delegation. (You can then add additional numbers like you can with other OIDs too)

Binary protocols have other benefits as well, such as not requiring escaping, and allowing binary data to be transferred is a way that is not as messy, not causing problems with character sets, etc.

[p_l]

That's why there was an entire section for unassigned numbers.

Binary protocols just meant you actually needed to implement serialiser/deserialiser and similar tooling instead of writing dumbest possible riff on strtok() and hoping your software won't be used anymore once DoD internet becomes mature

[cyberax]

> That's why there was an entire section for unassigned numbers.

That's also why the majority of OIDs in SNMP are rooted in the 1.3.6 hierarchy, which belongs to the DoD.

[p_l]

SNMP OIDs are in 1.3.6 because TCP/IP stack was once more well known as "DoD Internet".

And SNMP is explicitly a DoD Internet simplified alternative to CMIS