Very interesting. You're absolutely right that the fact that the
boundary includes the preceding CRLF allows us to solve this problem
only for things that follow text parts. One nit:
To get that effect in Andrew, I'd have to generate
multipart/mixed
text/plain (ending with an extra CRLF)
image/gif
text/plain (empty)
audio/basic
You don't actually mean "empty" -- you mean nothing but a CRLF. But I
get your point.
What I find myself wondering, however, is whether or not this isn't sort
of the same problem as the inline vs attachment problem. What you
describe for Slate is, I believe, a variant on the attachment model. Or
have I misunderstood? I could certainly imagine a third value for
"content-disposition" or YAMS (yet another mutlipart subtype) which
handled the model you describe.
There's also a meta-question we've never really explored, which is the
degree to which we EXPECT that a MIME message will appear identically in
radically different user interfaces. I have never had a very strong
expectation that this would be the case. (Compare the way the same
message appears in Andrew and a metamail-extended tty-oriented mail
reader and you'll see what I mean.) When we look at two systems which
seem superficially similar, such as Andrew and Slate, we may have a
greater expectation that the presentation will be absolutely identical,
but I'm not sure this is really reasonable when, as you point out, the
underlying document composition models are so different.
Another way of putting this is to ask what the consequences of getting
it wrong are. In this case, a Slate-generated message may appear
slightly ugly in Andrew, with a whole series of buttons in the "same
paragraph". An Andrew-generated document might appear either more or
less ugly than this in Slate, depending on the sophistication of the
implementation (i.e. if you get a separating part that is just plain
text containing nothing but a CRLF, how "in-your-face" does that appear
to the user?) But in any case, we're not talking about dire
consequences here -- it's still an enormous improvement over the
pre-MIME case, probably on the order of 98% correct interworking. That
doesn't mean we should stop there, but it means that we needn't hold
anything up because of it. If the solution turns out to be, for
example, new multipart subtypes, then we'll have graceful fallback to
the 98% level for implementations that don't understand the new subtypes
and treat them as "multipart/mixed". Similarly, if we opt for a
Content-Disposition extension, then implementations that don't support
that will automatically fall back to the 98% level we're at now.
I suspect that the bottom line is that there are LOTS of multipart
semantics that are desirable by different systems, and that we're going
to need several more of them. Fortunately, MIME can handle this -- it's
actually one of the greatest strengths of MIME compared to 1154, which
has only one (serial) multipart semantics, as I recently pointed out on
the IETF list. I guess I'm coming to feel that the right solution is to
define several new multipart subtypes, and to be glad that the rule
about "fallback to multipart/mixed if you don't recognize a multipart
subtype" is a part of RFC 1341. -- Nathaniel