We need to decide how to proceed. I don't see how we can have it both
ways -- we either allow trailing whitespace on boundary lines or we
allow one boundary string to be a leading substring of another. Which
one is more important? Requiring infinite lookahead is not acceptable in
my opinion.
The only argument I can see for allowing trailing whitespace in a boundary
is the fact that they are allowed to be defined in quotes. It doesn't make
any sense to me to require a rule which states that "boundary=" may not use
trailing white space *even if enclosed in quotes* (as was stated earlier).
Allowing free use of whitespace within a quoted field should be sacrosanct.
To counter that, I think allowing trailing whitespace makes life very
difficult for humans trying to "parse" a nontrivial MIME message. But we
can't go back now and disallow the definition of boundaries via quoted
strings.
The grammar for boundaries specifically disallows trailing whitespace as part
of the boundary string itself. This is done because lots of mail systems remove
trailing whitespace from lines. BITNET is the best known long-term offender,
but there are other examples as well.
There are also cases where systems add a blank or two to every line. This
is MUCH less common, but I do run into it every once in a while.
In either case, I believe we absolutely must allow a boundary string to be
a leading substring of another, otherwise any boundary generator which is
based on a characterized time stamp will break. Or to put it another way, to
specifically disallow it seems absurd!
Why? Why not prepend the character information rather than appending it?
Ned