The 7-bit Internet

The text-based aspect isn't bad in and of itself. It's the crazy moronic rules and pointlessly flexible syntax that makes it bad. It's the fact that "text-based" is often taken to mean "should allow humans to be flexible in writing it", instead of "uses ASCII". Oh, and UTF8 if you're lucky. If you dare want a non-ASCII value that needs to go into a header, you're toast.

HTTP: Comments inside headers, line folding, context-sensitive header value parsing, and on and on. There is zero legitimate need for these things, yet RFC writers cannot seem to help themselves and design the most complicated syntax as possible.

Text-based formats frequently trick people into thinking they're right because it looks easy on the surface to get something to work. Shit, most HTTP clients/servers aren't actually fully compliant.

It opens more possibility for security holes due to potentially ambiguous parsing (where one implementation misses an edge case, but another doesn't). Protocols are not programming languages. They don't need flexible syntax.

There's also crap left over from a time when people read/write these protocols by hand. Idiocy like the IETF preferred date formats "Sun, 06 Nov 1994". Really? Including "Sun", the English 3-letter abbreviation, in a protocol? How is that useful?

HTTP is being used more and more for high-performance work. Take a look at a high-perf text-based parser, and you see all sorts of ugly hacks. Like doing bitwise comparisons on word-sized integers to determine the request method. (Both my personal code and nginx ended up with similar solutions, so it's safe to say it's a common approach for perf.)

Having a proper binary format that can be quickly, unambiguously, and safely parsed is a huge boon for interoperability and performance. The slight detriment for analyzing raw bytes (which, when encrypted makes it all moot) is not worth it. For a popular protocol like HTTP, you're gonna have plenty of tools to properly parse and analyze.

IP, UDP and TCP aren't text based, and I have no problems regularly analyzing them, nor do they seem to have adoption issues. But you can bet your ass if UDP specified port numbers as a flexible text field, you'd find all sorts of fun bugs and implementation issues.

Edit: After skimming the HTTP 2.0 spec, implementing this as a text-based protocol sounds like a nightmare with no benefit. It's not like you're going to write multiple streams out by hand or something (and use some terrible multipart-mime approach, or another "fun" ASCII-delimiting-binary thing).

Or, as the langsec crowd claims, protocols don't need flexible syntax, lest they actually become programming languages.

Engineering should be about taking complex things and making them simple and easy (the best engineers do this), on the other hand you have engineers that try to add complexity because they understand something and over engineer it to obscure it on some premature optimization or cool factor. Taking something simple and making it more complex is the epitome of bad engineering.

Cool is useful and useful is simple or at least simple parts. Keep entry to technology simple, just like good games are simple to start, deeper in it gets more difficult. The door should be easy to enter even though the labyrinth might be immense.

While we can certainly wait and see whether people will balk and make changes, the only true way to stop it is to replace it.

If you can write a better set of protocols that meet the requirements, do it. If you can't then work with or support those that will.

I wonder if that was the original purpose of the protocol;)