Here's a few thoughts on the semantics of the multipart mixed and parallel
subtypes. I'm not trying to give a definition per se, but rather present
how I see the subtypes in use today in practice (in the metamail model) in
the hope that it may cause something to twig in the minds of the MIME authors
as to how the text may be sharpened.
These thoughts are coloured somewhat by the metamail way of looking at MIME,
so please bear with me if you aren't a great fan of that model. I'm also not
going to address issues such as printing, gatewaying, etc. I'm just interested
in the interactive message viewing semantics, rather than automatic processes.
As I see it, the parts of a multipart entity (be it mixed or parallel) can
be divided into 3 distinct groups:
* Those that are _always_ displayed to the user in whatever fashion is
appropriate for the output device. Content types such as text/plain
fall into this group. Software with built-in richtext support may
also include text/richtext, and GUI software may include some subtypes
of image.
* Those that _could_ be always displayed to the user, but it is prudent
(although not required) to get confirmation from the user first. In the
metamail model, anything that requires an external process to be run from
the mailcap file falls into this group.
* Those that _definitely_ need some form of user interaction. Usually these
are the content types the software and the mailcap file don't know about
requiring the user to specify a file to save in, etc. Alternatively,
where the default action may cause some change to the user's environment if
taken without confirmation (e.g. saving, printing, etc). Attachments may
also fall into this group.
OK, given these 3 groups, "parallel" differs from "mixed" in the following
way: the members of the second group are displayed to the user without any
user confirmation having taken place for a "parallel" multipart entity, whereas
confirmation is recommended for "mixed". (I say "recommended" rather than
"required" because some future software package might provide an option for
the user to disable prompts if he or she wishes).
Comments?
On another issue: I'm coming around to the idea of "Content-Disposition"
for attachments too now. It looks like producing the best trade-off of
functionality and backwards compatibility, and has a nice ring to it:
* Content-Type tells you what it is.
* Content-Transfer-Encoding tells you what transport encodings are present.
* Content-Disposition tells you what to do with it.
Putting "filename" into "Content-Disposition" as well will make the "what to
do with it" semantics even tighter.
Cheers,
Rhys.