The subtypes of multipart are there to tell your code how to interpret the
contents, just like any other subtype.
The difference between multipart/mixed and multipart/parallel is all
about presentation, not about interpretation. In that it is very
similar to the issue of attachments, and unlike the rest of the
subtypes.
I still disagree. I look at these things mostly from a gateway perspective, and
to me the mixed/parallel/alternative subtypes are not presentation issues at
all. Gateways should handle them very differently. Gateways for the most part
ignore presentation information unless there's a way to map it, which there
usually isn't. (As far as I can tell most other mail standards have yet to
consider the issues we're grappling with here).
An anecdote might help: I wrote the Servicemail package,
which automatically reads and responds to MIME mail. The mixed vs.
parallel distinction is the *only* part of MIME that has no meaning as
input to my software, simply because there is no presentation of
input messages. (Well, maybe there is a model of presentation to
programs, but it certainly is not temporal.)
I've written 4 MIME gateways thus far as well as a MIME mail server. Without
exception there's some processing distinction associated with each of the
various subtypes of multipart.
So if we want Content-type to be purely about interpretation, and I think
it should be, then we should (1) forget about multipart/attachments,
(2) remove multipart/parallel, (3) remove the "displayed serially"
semantics from multipart/mixed, and (4) figure out another way of
including presentation information. Content-Disposition is a good
idea, maybe Content-Presentation is more intuitive. Here's a new take:
presentation := "Content-Presentation" ":" style
style := "indirect" / "serial" / "parallel"
The semantics would be like this: inside the scope of a multipart/mixed,
all parts marked presentation parallel would be displayed immediately
and simultaneously, followed by parts marked presentation serial in the
order they appear, followed by a simultaneous presentation of pointers
(icons, a list box) for all parts marked indirect. If serial is the
default presentation, then multipart mixed without presentation markers
has the same semantics as now (it won't break current implementations).
I dislike this intensely for all the reasons I've already described. Even if we
ignore the presentation/interpretation issue, using a separate header for this
information is a bad idea because of all silly states it introduces when you
use it in contexts where no multipart/anything is to be found.
I would much rather add presentation information to the Content-Type
information, either as a parameter or as multipart/attachment, than splitting
off interpretation information specific to particular types to another header
line.
The use of a separate header line is nice for software like Servicemail
that doesn't have a presentation model, because it can simply ignore
Content-Presentation.
You can also ignore subtypes and parameters from the Content-Type header (it is
even appropriate to do just this in some situations). I fail to see how this
could possibly be an issue of any significance.
Ne