Marshall -
The problem is in both cases that software has already gone out with
these mistakes, and it is going to be difficult to exterminate it. Remember,
those mistakes appeared in pilot implementations, written by people who are
presumably aware of the design goals of the authors of MIME. If we can't get
it right, how can we expect those who weren't at the meetings to get it right!
As an example, consider that years after the bug in an ancient version of
BSD was fixed, we still have to worry about handling MAIL FROM commands in
SMTP that are missing the host name, or that have colon delimiters in the at-
domain-list instead of commas. This isn't documented in SMTP; rather, it's in
the folklore of how you get your SMTP server to be interoperable.
A strictly conforming MIME parser is not able to parse a parameter value
which has a dot in it unless that value is quoted. If that parameter value is
the boundary delimiter cookie, then the MIME parser won't get the correct
cookie and it won't be able to find any of the boundary parts. That is, if it
is strictly conforming.
It is probably going to be necessary to take the conservative view and
quote all parameter values when generating the header line, ignoring the
tspecial rule. It is probably going to be equally necessary to take the
liberal view in parsing and accept unquoted dots, again ignoring the tspecial
rule. All in the name of interoperability. So here we are, violating the
specification's BNF in intent and reality, and it isn't even up to Draft
Standard yet!
The same thing becomes true with the extra CRLF. The danger of the extra
CRLF is that a strictly conforming parser will ignore the first body part.
The BNF says that since the delimiter must be preceeded by a CRLF, a delimiter
at the start of the message is not a delimiter. Hence that whole thing
becomes a prelude.
It may not just be a broken MIME composer that fails to insert the extra
CRLF. As it was pointed out, mail gateways might eliminate extraneous leading
empty lines. The strictly conforming MIME parser will not see the first body
part as noted in the previous paragraph.
Both of these interoperability problems can lead to serious consequences
for a strictly conforming parser. If the answer is "don't be a strictly
conforming parser, break the rules", then I assert that the rules should be
changed to conform with reality.
I don't see why you are opposed to the change, unless you're playing
devil's advocate. The definition of tspecials is made simpler by the removal
of dot. We'll probably need to encourage the quoting of all parameter values
anyway. The definition of boundary delimiters is made cleaner by the proposed
change (although Ned disagrees), plus it's in keeping with the way SMTP works.
The double-dot rule of SMTP does not have an exception at the beginning of the
data; a message which begins with dot must be transmitted starting with two
dots.
-- Mark --