The authors of the SIP spec published another spec (RFC4475[1]) called "SIP torture tests", where they seem to take a perverse glee in showing how messed up their "human readable" syntax can get.
They even use the phrase "infer" in several places, encouraging systems to take obviously malformed packets and try to figure out what they meant.
Being liberal in accepting input, apart from security issues, seems to create a worse situation. Implementation A messes up something, but B seems to be OK with it. C then accidentally requires it, while D rejects it. Depending on how large and responsive the vendors behind those implementations are, you end up with a nasty state of affairs, with random hacks here and there.
It's hard enough to create unambiguous, comprehensible, specifications. Telling implementations to be liberal only makes it worse.
I had to only face the true horrors on one occasion, for a Responsys integration. They had the C# examples and the Java examples. The API that they offered for the two had differences because some methods would work with one, some with the other.
I'm a Perl programmer, so tried that. After all you just have to translate the language, right? Wrong. After banging my head against that mess for a week or so, I finally gave up, wrote the communication in Java, and had a Perl launcher for it.
They even use the phrase "infer" in several places, encouraging systems to take obviously malformed packets and try to figure out what they meant.
Being liberal in accepting input, apart from security issues, seems to create a worse situation. Implementation A messes up something, but B seems to be OK with it. C then accidentally requires it, while D rejects it. Depending on how large and responsive the vendors behind those implementations are, you end up with a nasty state of affairs, with random hacks here and there.
It's hard enough to create unambiguous, comprehensible, specifications. Telling implementations to be liberal only makes it worse.