On Mon, Mar 01, 2021 at 11:09:31PM -0500, Keith Moore wrote: > (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?) I had to deal with ugly things the TCG did, like creating non-string directory attributes. So I implemented automatic open type handling for an ASN.1 compiler. And now I can get beautiful JSON dumps of arbitrary ASN.1 things. And it wasn't very hard, and I wanted to thank Paul Hoffman and Jim Schaad for RFC 5912. And it made me think ASN.1 isn't the awful think people make it out to be (but BER/DER/CER are). > 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. Yes, well, and JSON too. I got into jq precisely because I needed to deal with overwrought structures in JSON. And look, that TCG stuff I mentioned above? Similar disease. Yes, that one involves ASN.1. > 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. [...] They have that ability regardless. > 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". Typically we try to bake in extensibility only. > 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. Examples? I don't think that's the case with any of the ASN.1-using protocols I've ever had to implement any part of or which I'm familiar with (e.g., PKIX, Kerberos, LDAP). None of them are laid out with C in mind, though all have C implementations, and all vary a fair bit in the internal struct layouts. I would think if you want nice alignment with C you'd want XDR, only maybe an 8-octet alignment version nowadays. > (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. ) I've not implemented OER, but I suspect that OER is efficient in run-time, and certainly in space needed. > 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. Nah, that's just rpcgen -- one particular implementation. Many JSON implementations do that too. You _can_ implement more flatbuffers-like strategies for XDR. Nico --
