I get the feeling with many mail implementations that
the implementors failed to appreciate that RFC822 was actually meant to be a
strict grammar at all.
That, and the "if it works for me, it must be okay" philosophy. e.g. the
programmer codes up a program that generates dates in yyyy-mm-dd hh:mm:ss
format, uses it to send a message to himself, and because his user agent
isn't set up to sort on the Date field he never notices that the dates
his program is generating aren't usable.
Perhaps the human-readability of it lends the
impression that it's *only* meant to be human readable. Or maybe something
closer to your explanation is also true in some cases: the grammar is
sufficiently daunting that implementors just aim for an approximation,
coupled with some basic compatibility tests.
Note that 2822 is arguably worse than 822 in this respect. 2822 tried
to be more precise in defining what a reader should accept, and as a
result it made it harder to understand what a sender should generate.
It's not clear to me what it would take to make implementors follow the
standard as written, and it's more of a psychology problem than a computer
science problem. My best current guess as to how to deal with the problem is
to assume that implementors are lazy, and make a point of giving them
something easy to implement.
That, and write the specifications in such a way as to leave as little doubt
as possible about how to do it. Maybe even give them code.
"A designer knows he has achieved perfection not when there is nothing left
to
add, but when there is nothing left to take away."
-- Antoine de Saint-Exupéry (1900-44)
one of my favorites.
--
--
Regime change 2004 - better late than never.