I think a recap at this point would be useful:
(1) The current specification (RFC1521) is ambiguous about whether or
not one boundary string can be a leading substring of another.
(2) The current draft of the final specification changed this so that
one boundary cannot be a leading substring of another. This was agreed
to on the list in October and was changed to make it possible to allow
for trailing whitespace without an arbitrary amount of lookahead.
(3) I screwed up both in not fixing the prose to match the new grammar and
in my initial response to Steve's query. I did not catch the
relationship between the two issues, and I thought that one had no impact
on the other. I apologize again for my inattentiveness here -- I should
not try to debug X.400 recipient extension handling code simulataneously
with doing standards work.
(4) Most people seem to have read the specification the way Steve did, which
is at odds with how it now reads.
(5) 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.
(6) Someone is going to have to change some code no matter what. We have
an interoperability problem caused by an ambiguity in the specification
that has to be resolved one way or the other.
(7) Speaking as an implementor, I could go either way on this. I don't generate
boundaries the way Eudora does, and I currently support Eudora's
boundaries. (I don't have a lookahead problem yet because I don't yet
support binary message formats completely. I plan to soon, however, and
I need to have this resolved before this will work right.)
Ned