[rfc-i] ABNF (RFC2234) vs HTTP's augmented BNF syntax (RFC822 + RFC2616)
blilly at erols.com
Thu Feb 17 07:47:18 PST 2005
> Date: 2005-02-15 15:41
> From: Dave Crocker <dhc2 at dcrocker.net>
> Although RFC822 is rife with errors, limitations, and other sources of very legitimate frustration, most of the interoperability problems with Internet mmail stem from there being a serious lack of effort to conform to the standard.
> It is not at all uncommon for a developer to have little or no familiarity with the formal specification of RFC822. (No, I'm not kidding.) Rather, they observe the behavior of one or another existing implications and intuit the specification from that.
> So, we need to be careful about detailed analyses, of the sort offered above, assuming that the problem is the document.
I suspect that a considerable *cause* for some developers resorting
to implementation based on observed behavior is the vagueness of the
formal specification. And there are certainly problems which go well
beyond vagueness; 822 requires a msg-id in the "id" component of a
Received field which in turn requires an '@', whereas RFC 821
requires a "<string>", which forbids an '@'. RFC 1123 attempted to
address the situation, but made matters worse by claiming that the
RFC 822 specification of msg-id merely "suggested" an '@'. There is
simply no way to include an "id" component in a Received field in
such a way that it conforms to all of RFCs 821, 822, 2821, and 2822.
What's a developer to do? Is it at all surprising that some simply
ignore the specifications out of frustration?
> From a meta-view, one of the strategic errors in RFC733/RFC822 was, I believe, allowing TOO MUCH variance in how things are formatted. There were good reasons for making the choice to support multiple forms, but it turns out to have caused significant, long-term problems.
Yes; since that time, that has been formalized in RFC 1958 section
3.2. Unfortunately, RFC 1958 apparently isn't as widely read as it
More information about the rfc-interest