Now blogging at diego's weblog. See you over there!

postel's law is for implementors, not designers

Another discussion that recently flared up (again) is regarding the applicability of constraints within specifications, more specifically (heh) of constraints that should or should not be placed in the Atom API. The first I heard about this was through this post on Mark's weblog, where among other things he says:

Another entire class of unhelpful suggestions that seems to pop up on a regular basis is unproductive mandates about how producers can produce Atom feeds, or how clients can consume them. Things like “let’s mandate that feeds can’t use CDATA blocks” (runs contrary to the XML specification), or “let’s mandate that feeds can’t contain processing instructions” (technically possible, but to what purpose?), or “let’s mandate that clients can only consume feeds with conforming XML parsers”.

This last one is interesting, in that it tries to wish away Postel’s Law (originally stated in RFC 793 as “be conservative in what you do, be liberal in what you accept from others”). Various people have tried to mandate this principle out of existence, some going so far as to claim that Postel’s Law should not apply to XML, because (apparently) the three letters “X”, “M”, and “L” are a magical combination that signal a glorious revolution that somehow overturns the fundamental principles of interoperability.

There are no exceptions to Postel’s Law. Anyone who tries to tell you differently is probably a client-side developer who wants the entire world to change so that their life might be 0.00001% easier. The world doesn’t work that way.

Mark then goes on to describe the ability of his ultra-liberal feed parser to handle different types of RSS, RDF and Atom. (Note: I do agree with Mark that CDATA statements should be permitted, as per the XML spec). In fact I do agree with Mark's statement, but I don't agree with the context in which he applies it.

Today, Dave points to a message on the Atom-syntax mailing list where Bob Wyman gives his view on the barriers created by the "ultra-liberal" approach to specifications, using HTML as an example.

I italicized the word "specifications" because I think there's a disconnect in the discussion here, and the context in which Postel's Law is being applied is at the center of it.

As I understand it, Mark is saying that writing down constraints in the Atom spec (or any other for that matter) is something to be avoided when possible, because people will do whatever they want anyway, and it's not a big deal (and he gives his parser as an example). But whether his parser or any other can deal with anything you throw at it is beside the point I think, or rather it proves that Postel's law is properly applied to implementation, but it doesn't prove that it applies to design.

Mark quotes the original expression of Postel's Law in RFC 793, but his quote is incomplete. Here is the full quote:

2.10. Robustness Principle

TCP implementations will follow a general principle of robustness: be conservative in what you do, be liberal in what you accept from others.

(my emphasis). The comment in the RFC clearly states that implementations will be flexible, not the spec itself. I agree with Mark's statement: there are no exceptions to Postel's law. But I disagree in how he applies it, because it doesn't affect design, but rather implementation.

Getting a little bit into the semantic of things, I think it's interesting to note that placing a comment like that on the RFC is actually defining accepted practice (dealing with reality rather than the abstractions of the spec) and so it is a constraint (a constraint that requests you accept anything, rather than reject it, is nevertheless a constraint). So the fact that this "Robustness principle" is within that particular RFC as an example shows that placing constraints is a good idea.

Implementations can and often do differ from specs, unintentionally (ie., because of a bug) or otherwise. But the less constraints there are in a spec, the easier it is to get away with extensions that kill interoperability. So I don't think it's bad to say what's "within spec" and what is not within spec. Saying flat-out that "constraints are bad" is not a good idea IMO.

One example of a reasonable constraint that I think would be useful for Atom would be to say that if an entry's content is not text or HTML/XHTML (e.g., it's a Word document, something that as far as I can see could be done on an Atom feed according to the current spec) then the feed must provide the equivalent text in plain text or HTML. Sure, it might happen that someone starts serving word documents, but they'd be clearly disregaring the spec, and so taking a big chance. Maybe they can pull it off. Just as Netscape introduced new tags that they liked when they had 80 or 90% market share. But when that happened, no one had any doubts that using that tag was "non-standard". And that's a plus I think.

So, my opinion in a nutshell: constraints are good. The more things can be defined with the agreement of those involved, the better, since once something is "out in the wild" accepted practices emerge and the ability to place new constraints (e.g., to fix problems) becomes more limited, as we all know.

What I would say, then, is: Postel's law has no exceptions, but it applies to implementation, not design.

Posted by diego on January 11 2004 at 2:23 PM

Copyright © Diego Doval 2002-2011.
Powered by
Movable Type 4.37