Plain text protocols suck. They give you the illusion of readability, and they can make what looks like the obvious solution turn out to be bug-ridden and rife with security holes. The readability is overrated--even in protocols like XML or JSON, most of the time I need to filter down to a small subset anyways, which requires me to write some sort of tool. And if you're already using a tool for all of your poking, what's the benefit to the input format? A good tag/length/value format (particularly when the tag implies how to interpret the value without needing to know a grammar, sorry ASN.1) is even easier to decode than a CRLF-based protocol, since you don't worry about things like "how long could this line be" or "does a bare LF count as a CRLF? What do I need to do for compatibility?"
Plain text protocols help keep interoperability honest and open. They also have benefits that are often overlooked, such as more easily avoiding integer overflow and endian issues.
> If you're already using a tool
Often, I'm not.
> illusion of readability
That depends entirely on the protocol design; some are better than others. Binary protocol can also be a mess. More importantly, binary protocols will always require external definitions, while some text protocols do not.
> bug-ridden and rife with security holes
Changing from readable tokens and ASCIIified intege4rs to packed binary doesn't magically fix bus or security holes.
> what do I need to do for compatibility
That's easy: use the robustness principle[1].
(and most RFC-based protocols say you should send a CRLF).
A possible argument against this could...
> how long could this line be
...also be an argument against length fields. If you want reliable parsing - a very good idea - a good argument[2] can be made to only use context-free protocols (i.e. use parser-combinators).
To anyone who takes your advice on the robustness principle, don't. Liberal acceptance is a maintenance and security nightmare. Be strict on all boundaries and provide clear errors.
The robustness principle is fine, but it does need to be strictly interpreted, which I should have mentioned. Too often robustness is used as a license to be sloppy or to abuse lenient parsers with invalid input.
Meredith covers this specific issue at 33:25 in her 28c3 talk I referenced ([2]). "Be definite in what you accept" can emulate traditional "liberal" parsers if the compatibility is strictly defined in the grammar.
I really should have phrased that better; the robustness principle is great historically, and is therefor necessary in many current protocols, but newer protocols should be using well-defined either regular grammars or deterministic context-free grammars. As Meredith and Sergey explain in that talk, moving away form Turing complete protocols would prevent an important class of exploits.
> Plain text protocols suck. They give you the illusion of readability...
They don't, and the readability is a feature.
I'm not sure how you conflate XML and JSON as synonymous to "protocol" and also requiring tools to filter, but than imply that a "good tag/length/value" format would somehow be superior to the former.
Exactly what feature binary protocols can have that make protocols less bug ridden and with less security holes?
Because, well except for readability and ease of debug, that you lose completely by going binary, and message size that improves by going binary, I can't find any other difference.
An honest question: Is it possible that they suck for you and people like you, skilled, experienced engineers with sophisticated tools, and with much less time than money - but they don't suck for less experienced, less equipped, hackers or tinkerers with time to try things but little money or expertise?
Remember that those people built quite a few things, from Facebook to Napster to Dell to the web browser to the web itself (just off the top of my head). Empowering them is arguably the key to innovation.
Last I checked, ASCII is an encoding, and was transmitted in packets, so if you're relying on tools to decode and unpack your messages, why not simply upgrade them?
Also, people don't seem to complain about the cost of HTTP over SSL in these discussions on HTTP/2. I've never understood that. If you're allowing for TLS, why not HTTP/2?