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 mailing list
Ietf(_at_)ietf(_dot_)org
https://www1.ietf.org/mailman/listinfo/ietf