(wondering what brought up this subject... did someone decide that this
is the week to rant about every past poor protocol design choice that we
have to deal with?)
On 3/1/21 8:34 PM, Larry Masinter wrote:
Rich formalisms and separation of syntax and "encoding rules" seem
counter-productive.
<soapbox>
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.
And because it's difficult to extend such protocols when needed, there's
pressure to get things "right" the first time, which is often
interpreted as "let's make sure specify every feature that could
possibly be needed".
A related problem is setting up a tight binding between say an ASN.1
structure and a C struct which imposes even more rigidity and subtle bugs.
There are some situations in which you need rigid type checking and a
minimum of permitted variation, and probably X.509v3+DER is a good
example of such a situation. But this should not be the default.
And sure, you can use SEQUENCE or OPTIONAL or whatever to define ASN.1
structures that aren't so rigid, but these tend to be used sparingly
because people get enamored with their ability to define grandiose
structures that solve all of the world's problems.
(Encodings are separate issues but I have yet to see an encoding of
ASN.1 that is really efficient to either encode or decode. Not saying it
cannot be done, but there's sort of an expectation that marshaling has
to be done one datum at a time, in the sequence that they appear on the
wire, and that slows things down by itself. )
Nico WIlliams wrote:
I've never heard a bad thing uttered about XDR.
Besides being too rigid in the same way that ASN.1 is (for many
applications), XDR is also grossly inefficient (in time more than space,
though there's some space inefficiency) in both encoding and decoding,
requiring extra memory copies and mallocs/frees to convert between
on-the-wire and internal representations, and this slows things down
tremendously.
(You're welcome.)
</soapbox>
Keith
