Re: What ASN.1 got right

[Keith Moore <[e-mail]>]

(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