On Mon, Mar 01, 2021 at 11:09:31PM -0500, Keith Moore wrote: > There's something I used to call "ASN.1 disease", but it applies equally to > XDR, some uses of XML, and a lot of other systems used to define data > structures used in communications. > > The basic problem is that if you give people the ability to generate and > require arbitrarily complex type-checked data structures, protocol designers > will use that ability to create overly complex structures. This in turn > makes protocols and implementations much more brittle and less interoperable > than they should be. Every non-optional field must be specified and > checked whether it is needed or not, it's more difficult to extend such > protocols when needed, and implementation bugs that break things at a level > which is hard to work around are far too common. There's another side effect which this often enables (although arguably this is the fault of the working group / standards committee) which is that it becomes easier to settle disagreements by adding large numbers of optional fields / substructures. If you are using fixed-length encodings, such as what is found in, say PPP, you can still have extensibility, but since it's painful to create the ASCII-art packet formats, I theorize this acts as a check against unneceessary protocol complexity. ASN.1-specified protocols tend to be far more complex, because it's *easier* to create complexity, and this results in implementors having to agree on profiles which are the subset of the protocol that implementations _actually_ implement, and if there are different profiles with different subset, there goes any hope of interoperability. - Ted
