On Sat, 4 Jul 92 14:59:55 EDT, Frank T. Solensky wrote:
I disagree.. This type of thing was exactly why RFCs 1122 and 1123 were
created. If it's not already described in RFC-1123, perhaps it should
be considered as one of the items to be added.
As I see it, the Host Requirements RFCs were created to depreciate some
functionalities which were never used, to make minor tweaks to the
specifications that had already been generally accepted as correct, and to
specifically ban some practices which were considered particularly offensive
by the community (many of which were already clearly invalid according to the
original standards, but which certain individuals did nontheless).
That did not, however, in any way deal with the issue of folklore. Host
Requirements deals in technical matters where reality and the specification
can be made to converge. It does not deal in those cases where reality and
the specification do not converge, but it is politically infeasible to change
the specification.
In particular, it does not deal with common violations of the specification
which make more sense than the specification itself, and thus are not
generally considered offensive enough by the community to merit a ban.
Much of this folklore is in areas which some are unwilling to admit even
exists. Often, these are the same individuals who defend the flaw in the
original specification. The notion of publishing such folklore in a Host
Requirements document is absurd, given this situation.
An example of folklore in the making, and of current long-term folkore:
Those of you in ietf-822 know that I have been trying to convince people that
MIME should allow things such as
;FILE=foo.tar.Z
;BOUNDARY=xyzzy.001.aax
instead of insisting upon
;FILE="foo.tar.Z"
;BOUNDARY="xyzzy.001.aax"
which is the only form that is valid in the present MIME. I am seeing the
unquoted versions in mail from other implementations now. Among other things,
there are examples in the MIME document which use the unquoted form. I
consider the requirement [the inclusion of `.' in `tspecials'] silly, and have
campaigned for its removal. This has met with formidable opposition.
Given the difficulty in fixing this, how can you possibly deal with
From: John T. Doe <jdoe(_at_)foo(_dot_)bar(_dot_)com>
which violates a similiar rule (which I also consider silly) in RFC-822?
If you claim these are invalid and deserve a `parse error', you are burying
your head in the sand. Your users will crucify you if you tell them they
can't read their mail because of some trivial specification BNF rule. No, if
you can't get the specification fixed, you just change your parse engine so
you accept it anyway.
Other e-mail related folklore:
. the CR is optional in Internet newlines (UNIX says it's so)
. leading or tailing spaces are permitted in host names given to SMTP (NeXT
is a big offender here).
. beware of using the SMTP return path for its intended purpose, since it is
a reply address for many people.
. Errors-To:
. % as a soft @, and mailers other than that to the right of the @ thinking
they know the semantics of %
. comments used to convey personal names
etc.