Again, I'm not addressing how your gateways contrue multipart subtypes, but
just what RFC 1341 says:
...
I've quoted these sub-sub-sections IN THEIR ENTIRETY.
FYI, you didn't get all the text that's describes this stuff.
There is nothing
there besides presentation commitments like "displayed serially" and
"presented in parallel".
We're getting all twisted around here because we're using different definitions
for the verb "present" at different times. This is probably my fault; I've been
using the term "presented" in this discussion as meaning "those things that a
user agent does to show the user the message". When coupled with the stuff in
the RFC that says parallel may get interpreted as mixed, this tends towards
being nothing more than a viewing recommendation.
However, the reality is that in the context of the RFC the term is much broader
(and happens to agree much better with my dictionary); we're talking in very
general terms about how the MIME representation of data is "presented". I
should never have used the term "presented" in a narrow sense since it clearly
conflicts with the RFC.
I firmly believe that the mixed/parallel/alternative information is an intimate
part of the discription of the nature of the data itself. The only case you've
made to counter my position is that you've written software that has chosen
this information, and therefore it must be nothing more than a recommendation
for how to view it and is therefore not intimately tied to the data. My
counterexample is simply that I've seen and used just the opposite approach.
We can take several conclusions from this:
(1) We're never going to convince each other about this.
(2) It is really a pointless discussion because even if I agreed with you I
and many others would object to such a major change in MIME at this point.
This is simply not a big enough deal to reset things to Proposed Standard
to fix (granting for the moment that it is broken). We can always define
additional subtypes, headers, or both in a separate document in order to
clarify or correct this.
(3) Keith Moore's point about the attachment stuff being too premature to
standardize is well taken. We need some concrete proposals and some
experience before we can proceed on any of this.
(4) The remaining issue here is then how do we clarify what mixed and parallel
mean without changing the intent behind them. If anyone wants to define a
multipart/serial or whatever by all means do so.
I think the suggested changes to the wording about mixed are good and I
recommend that we make them. This leaves parallel. Now, since the intent of the
RFC is quite clearly that parallel objects are to be presented simultaneously,
and the term "presented" can be taken to mean "things that you do with the
MIME representation", the question then is do we want to change this wording. I
would welcome adding some extra verbs beyond "present" in order to make it
clear that this stuff goes being just a recommendation of how you handle the
subparts in your MIME viewer.
Ned