This is simply incorrect. Most clients&#x2F;servers will get edge cases wrong. Things like line endings. Or line folding. Comments in headers.<p>Not even getting into sillier things that aren&#x27;t just parsing, like absolute vs relative URI in request line vs host header. Or how some headers have different parse semantics.<p>SIP uses the same format as HTTP and the number of <i>basic</i> interop (and security!) issues due to parsing is astounding.<p>Parsing human writeable text <i>is hard</i>, proven via such interop issues. The key here is that this is &quot;human writeable&quot;. If HTTP, for instance, eliminated free formatting and CRLF in favour of just LF that&#x27;d be a huge improvement. You could actually parse all headers, correctly, just doing:<p><pre><code>  Var parts = msg.split(\n\n)
  Var hdrs = parts[0].split(\n).map(|x| {
    Var xs = x.split(:)
    xs.[0], xs.[1] }
</code></pre>
Instead, people write similar code, <i>thinking</i> it works, and might achieve interop with some popular implementations that handle things well enough.<p>If they used a tight text protocol (which really is basically a bloated binary protocol, just eg with newline instead of null as a terminator), none of these encoding issues would exist. It&#x27;d still be pointlessly inefficient, but reduce basic parse issues.<p>In fact the IETF has belatedly realised this for HTTP and the latest RFC kills spacing around colon and line folding. In the name of security, since it was causing actual issues since implementations weren&#x27;t reading messages the same way.<p>And funny enough, this updated HTTP1.1 RFC breaks preciously working implementations.