Subject: RE: Best practice for data encoding?

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Tue, 6 Jun 2006 09:50:22 -0700

> From: Steven M. Bellovin [mailto:[email-masked]] 

> 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 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: "Steven M. Bellovin" <[email-masked]>
Date: Tue, 6 Jun 2006 13:10:14 -0400

On Tue, 6 Jun 2006 09:50:22 -0700, "Hallam-Baker, Phillip"
<[email-masked]> wrote:

> 
> 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.

Hoare has been a great influence on my thinking, too.  I particularly
recall his Turing Award lecture, where he noted:

	There are two ways of constructing a software design: One way is
	to make it so simple that there are obviously no deficiencies, and
	the other way is to make it so complicated that there are no
	obvious deficiencies. The first method is far more difficult.

(In that same lecture, he warned of security issues from not checking
array bounds at run-time, but that's a separate rant.)

		--Steven M. Bellovin, http://www.cs.columbia.edu/~smb

---

From: "Robert Sayre" <[email-masked]>
Date: Tue, 6 Jun 2006 21:52:12 -0400

On 6/6/06, Hallam-Baker, Phillip <[email-masked]> wrote:
>
> 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.

JSON <http://www.json.org> seems like a better fit for the use cases
discussed here. You get better data types, retain convenient ASCII
notation for unicode characters, and lose lots of XML baggage.

draft-crockford-jsonorg-json-04.txt is in the RFC queue, headed for
informational status.

-- 

Robert Sayre

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Jun 2006 09:51:29 +0200

On Tue, Jun 06, 2006 at 09:50:22AM -0700,
 Hallam-Baker, Phillip <[email-masked]> wrote 
 a message of 42 lines which said:

> At this point XML is not a bad choice for data encoding.

+1

> 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.

There are other schema languages than the bloated W3C Schema. The most
common is RelaxNG (http://www.relaxng.org/).

In the IETF land, while RFC 3730 and 3981 unfortunately use W3C
Schema, RFC 4287 uses RelaxNG.

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Wed, 7 Jun 2006 09:51:29 +0200

+1