First of all, yes, this issue is in the noise compared to the overall
value that MIME is providing for interoperability. That's why I called it
a "minor incompatibility".
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.
Well, actually I don't think so. The inline vs. attachment problem has to do
with how "in your face" the included object is. That's a big issue - do I
see it fully exploded or do I see a small little representation of it? It has a
direct correlation with standard protocols for paper as well as electronic mail
attachments and could conceivably have a big impact on user's perceptions
of interoperability between systems that handle it differently. Getting it
right
is truly important.
This issue is a bit more subtle, as it has much more to do with subtleties of
formatting than major issues of presentation.
Also, I don't think simply adding another multipart type is sufficient. This
really
has to do with nesting of types, in the typical case nesting of anything in a
text fabric. I suppose you could define something like "multipart/joined", but
then you'd have to define what "joined" meant. It would be very dependent
on the "fabric" in which the objects were presumed to be embedded. OK,
how about:
Content-Type: multipart/joined; boundary="stuff"
Content-Fabric: text/plain; charset="us-ascii"
which implies that the multipart objects should be treated as if they
were embedded in text. In the text case its clear what "embedded" means
(treat it as a character). It might be more difficult in something like a
spreadsheet
with embedded objects - you need to specify where the object is embedded.
Where does that control information go?
My guess is that most implementations will handle things like Slate does and
ignore this issue of the extra CRLF that does or does not end some text pasage.
That's partly because its easier and partly because the spec doesn't bring it
out very much. In the spec it is an issue of carefully describing precisely
what data
is associated with what object when you break up a multipart object. The fact
that it also has subtle formatting implications isn't obvious at all.
Anyway, I don't think this should impact the movement of MIME along the
standards process.
Terry