On Sun, 18 Feb 2007, Mark Crispin wrote:
That's why RFC 1730 and later went to such efforts to state the actual rules in picayune detail. What was "good enough" in 1989 ceased to be "good enough" just a few years later...
I actually prefer the more detailed RFCs since they leave less room for ambiguity. Once again, take our old MTA as an example. The problem that made it end up as unmaintainable was having to add more and more special cases for bugs in other MTA:s. Look at the sendmail grammar, it is full of rules dealing with misinterpretation of RFC 822.
RFC 822 is a good example of a specification that you have to interpret in the light of "common sense", or rather as how "common sense" was interpreted in the early 1980s. Hence the need for RFC 2822...
I would say that RFC 2822 is Postel's robustness principle in a nutshell. It makes the old misinterpretations into standard, "updating it to reflect current practice" as it states in the introduction. That's the first half of Postel ("be liberal in what you accept").
Further, 2822 clarifies the standard to leave less room for new misinterpretations, and that's the other half of Postel ("be conservative in what you send").
These days most MTA:s behave reasonable well, and if an RFC with "picayune" details made the difference, I don't see anything wrong with that. After all, that's what all the RFC's are about, making the Internet community talk the same language.
/Per _______________________________________________ Imap-uw mailing list Imap-uw@u.washington.edu https://mailman1.u.washington.edu/mailman/listinfo/imap-uw
