Implementations are required to ignore trailing whitespace on boundary
lines. If implementations can't do a match on the "<CRLF>--outer",
then they have to be able to do an *arbitrary* amount of lookahead, to
make sure there isn't a non-whitespace octet between the 35 megabytes
of spaces/tabs and the following CRLF.
I'm sorry to have to say it, but you're absoltuely right. I remember this
discussion now. And you're right -- the combination of the new LWSP rules make
this a really tough problem in terms of lookahead.
I'm really sorry I forgot about this previous discussion and conclusion. And if
you look carefully at the grammar rather than the prose it does make it clear
that the match is made on just the delimiter, that is CRLF--boundary. This in
turn implies that the scheme Eudora is using is in conflict with the current
draft.
Gee, I feel stupid about this. I had done all the changes to back up what
we had agreed to on the list.
We had a perfectly good grammar worked out on the list around the 25th of
October. Can't we just stick with that?
The problem is that the grammar got changed but the prose didn't get changed to
match it everywhere. In particular, there was a session that clearly described
the creation of a boundary delimiter line that did not allow for LWSP at the
end. And another prose section supported the Eudora approach. This, combined
with the confusing terminology, makes it all more than a little ambiguous.
I don't know how I missed the two sections in the prose, but I did.
I'm going to make the terminology consistent, correct the prose to match the
grammar, stop worrying at the thing, and post a new draft ASAP. And we'll see
how it goes from there. It now seems to me that we have to choosed between
allowing LWSP at the end and allowing one boundary to be a substring of
another.
Sorry again for the confusion.
Ned