Sigh... I hate to reopen a topic that appeared closed, but I feel I have to.
As I mentioned in passing in a previous message, I have produced a
complete implementation of RFC-XXXX as it now stands. For the most
part, I found it straightforward to implement. (Of course, I'm the
wrong person to comment on whether the specification was adequate, since
I knew the intent of the author. Thus all I'm really saying is that
implementing what I *meant* to say is straightforward; it is for others
to judge whether I said it clearly enough.)
However, there was one aspect of the RFC that surprised me with its
potential for causing problems for implementers. That is the decision
that the final portion of a multipart message -- the "postfix" following
the last boundary delimiter -- is to be ignored, or simply thrown away.
Here's why:
Imagine that you're a piece of code reading in a multipart message.
Imagine further that you're in a UNIX-like environment where it is
natural to communicate via pipes. The most simple implementation I can
imagine -- not precisely what I implemented, by the way -- is to pass
each encapsulated part via a pipe to a process that will "handle" a
single part. (Before you flame, I'm not claiming this is the "only" or
"correct" way to implement it, but it is a plausible and straightforward
one, particularly if you assume the presence of lots of external
programs that handle specific content-types such as images or audio.)
The problem is that when you read in a delimiter, you have no way of
telling if you're at the end of the last part or not. Imagine, in the
worst case, that the "postfix" area is very large. You don't have any
way to tell that it is indeed a postfix, rather than another
encapsulation, until you get to the end of it. If you're reading from a
pipe, rather than a file, you can't afford to throw away what you read,
so what are you supposed to do with it? Save it in memory? Save it in
a temporary file? If only you knew for sure whether or not it was
another body part, you could just send it down a pipe to an appropriate
program (the "popen" solution in UNIX).
I regard this as an unacceptable extra burden for implementers because
it is so avoidable. I can think of two solutions, though there may well
be others:
1. Change the definition so that a postfix is simply NOT ALLOWED,
rather than just ignored. This is slightly problematic because some
MTA's might add trailing blank lines to muddy the waters.
2. Change the definition so that a postfix is considered another
encapsulated part. Or, to put it more formally, the multipart syntax
becomes
body := 1*encapsulation
encapsulation := delimiter message CRLF
Personally, I prefer solution #2, based on my experience with the
prototype implementation, but I'm open to other ideas. What I'm really
unhappy with is the idea that when you read in a delimiter, you can't
tell whether what follows it is another encapsulated message or just
some trailing garbage that has to be ignored. That's what I'd like to
fix. -- Nathaniel