Re: OT: Re: Less is more

> I get the feeling with many mail implementations that=20
> the implementors failed to appreciate that RFC822 was actually meant to=
 be a=20
> strict grammar at all.

That, and the "if it works for me, it must be okay" philosophy.  e.g. the=
=20
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=20
> impression that it's *only* meant to be human readable. Or maybe someth=
ing=20
> closer to your explanation is also true in some cases: the grammar is=20
> sufficiently daunting that implementors just aim for an approximation,=20
> 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=20
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=
=20
> standard as written, and it's more of a psychology problem than a compu=
ter=20
> science problem. My best current guess as to how to deal with the probl=
em is=20
> to assume that implementors are lazy, and make a point of giving them=20
> something easy to implement.=20

That, and write the specifications in such a way as to leave as little do=
ubt
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=20
> add, but when there is nothing left to take away."
> -- Antoine de Saint-Exup=E9ry (1900-44)

one of my favorites.
--=20
--
Regime change 2004 - better late than never.