On Mon, Jun 05, 2006 at 08:21:29PM -0400, Steven M. Bellovin wrote: > > More precisely -- when something is sufficiently complex, it's inherently > bug-prone. That is indeed a good reason to push back on a design. The > question to ask is whether the *problem* is inherently complex -- when the > complexity of the solution significanlty exceeds the inherent complexity of > the problem, you've probably made a mistake. When the problem itself is > sufficiently complex, it's fair to ask if it should be solved. Remember > point (3) of RFC 1925. One of the complaints about ASN.1 is that it is an enabler of complexity. It becomes easy to specify some arbitrarily complex data structures, and very often with that complexity comes all sorts of problems. To be fair, though, the same thing can be said of XML (and I'm not a big fan of a number of specifications utilizing XML either, for the same reason), and ultimately, "you can write Fortran in any language". Ultimately, I have to agree with Steve, it's not the encoding, it's going to about asking the right questions at the design phase more than anything else, at least as far as the protocol is concerned. As far as implementation issues, it is true that ASN.1 doesn't map particularly well to standard programming types commonly in use, although if you constrain the types used in the protocol that issue can be relative easily avoided (so would using XML, or a simpler ad-hoc encoding scheme). I don't think there is any right answer here, although my personal feelings about ASN.1 can still be summed up in the aphorism, "Friends don't let friends use ASN.1", but that's mostly due to psychic scars caused by my having to deal with the Kerboers v5 protocol's use of ASN.1, and the feature and design bloat that resulted from it. - Ted _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf