Richard Robinson wrote:
| On Wed, 17 Jan 2001 [EMAIL PROTECTED] wrote:
| > John Chambers says -
| > >The protocol has a foolproof way of dealing
| > >with this, of course, but we have had a rush of companies
| > >recently who can't be bothered to implement the protocol
| > >correctly.
| >
| > This is just the sort of thing that can happen when a lot of independent
| > developers work in the same field introducing their own innovations with
| > little regard for a generally accepted standard or the work that others do.
| > The system that comes out top depends on who has the most clout rather than
| > which is best.
|
| or on who's heard of RFC's ?
More like who's heard of them (as evidenced by the fact that they do
implement the SMTP protocol, hoever poorly), but decide to make their
own gratuitous changes to it.
These email problems aren't caused by software that implements clever
extensions. Extensions are generally not all that big a problem, as
long as they don't break anything that meets the standard. Similarly,
abc extensions aren't all that much of a problem, aside from the
difficulties that they cause for people with tools that don't
implement them. Things like V: and w: and %% lines are easy enough to
ignore, as are the assorted other annotations and ornaments that you
see scattered in some abc. The success that abc2ps has at
interpreting this list's signatures as music even qualifies as an
example of how an "extension" doesn't cause much of a problem.
The real problem in both cases is gratuitous violations of the
standard. Thus, email programs pretend to speak SMTP, but don't do
the dot insertion and deletion properly. This is hardly excusable, as
even the most incompetent programmer could figure out how to do it
right, and RFC 821 states it quite clearly and unambiguously.
Similarly, the ">From" thing that comes from uucp mail is trivial to
implement correctly, and there's no excuse for the '>' ever appearing
in the end message.
A better parallel in abc would be the software that uses a variant
scheme for indicating end of staff. This is a violation of the
standard for no apparent reason. Granted, the standard scheme might
not be the best, considering the problems with the idiotic line
wrapping that is inflicted by some email software. But aside from
this, it's not a bad way to indicate staff ends, and there's no good
reason to violate it.
Of course, one obvious conclusion from such arguments is that what we
might want is a minimal standard. And we want to keep the developers
talking so that they don't implement conflicting extensions.
To subscribe/unsubscribe, point your browser to: http://www.tullochgorm.com/lists.html
