> From: Steven M. Bellovin [mailto:smb@xxxxxxxxxxxxxxx] > 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. I think that the term 'too complex' is probably meaningless and is in any case an inaccurate explanation for the miseries of ASN.1 which are rather different to the ones normally given. People push back on protocols all the time for a range of reasons. Too complex is a typically vague and unhelpful pushback. I note that all too often the complexity of deployed protocols is the result of efforts of people to reduce the complexity of the system to the point where it was insufficient for the intended task. Having had Tony Hoare as my college tutor at Oxford I have experienced a particularly uncompromising approach to complexity. However the point Hoare makes repeatedly is as simple as possible but no simpler. In the case of ASN.1 I think the real problem is not the 'complexity' of the encoding, it's the mismatch between the encoding used and the data types supported in the languages that are used to implement ASN.1 systems. DER encoding is most certainly a painful disaster, certainly DER encoding is completely unnecessary in X.509 which is empirically demonstrated by the fact that the Internet worked just fine without anyone noticing (ok one person noticed) in the days when CAs issued BER encoded certs. The real pain in ASN.1 comes from having to deal with piles of unnecessary serialization/deserialization code. The real power of S-Expressions is not the simplicity of the S-Expression. Dealing with large structures in S-Expressions is a tedious pain to put it mildly. The code to deal with serialization/deserialization is avoided because the data structures are introspective (at least in Symbolics LISP which is the only one I ever used). If ASN.1 had been done right it would have been possible to generate the serialization/deserialization code automatically from native data structures in the way that .NET allows XML serialization classes to be generated automatically. Unfortunately ASN.1 went into committee as a good idea and came out a camel. And all of the attempts to remove the hump since have merely created new humps. At this point XML is not a bad choice for data encoding. I would like to see the baroque SGML legacy abandonded (in particular eliminate DTDs entirely). XML is not a perfect choice but is is not a bad one and done right can be efficient. The problem in XML is that XML Schema was botched and in particular namespaces and composition are botched. I think this could be fixed, perhaps. _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf