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
I'm just going by what 1341 says, and the only distinction is makes between
multipart mixed and parallel is in terms of "displayed serially" vs.
"displayed simultaneously". That's not a presentation issue?
Sure it is in this context, and so is all the information in the Content-Type
header, and the Content-Id header, and the Content-Description header, and so
on. It is rather difficult to present much of anything without knowing
what its Content-Type is!
Pretty much everything in MIME can be characterized as a presentation issue
it you take it to an extreme.
The point I'm trying to make here is and has always been that these things
(parallel, serial, and the rest of the Content-Type information) are not
purely presentational in nature, whereas the disposition information is.
And I should have made it clear that I meant purely presentational, although
I think it was clear from context.
I'm also quite prepared to be proven wrong on the notion that disposition
information is purely presentational in nature; I simply have not seen any
counterexample yet.
I'm glad others are talking about removing "displayed serially" from
multipart/mixed, but multipart/parallel should be fixed as well. In the
end, multipart/mixed should mean "here are some things in a meaningful order"
and multipart/parallel should mean "here are some things in no particular
order".
This is certainly not the intent of multipart/parallel or multipart/mixed.
You're essentially proposing that multipart/parallel take on the current
meaning of multipart/mixed and that multipart/mixed take on a new meaning not
presently defined (it is also not a useful meaning as far as I can tell). The
current meaning multipart/parallel would then be lost.
Needless to say I am utterly and totally opposed to all of this. Even granting
that the loss of the present definition of multpart/parallel would be a Good
Thing, there is no chance that such a major change could be made to MIME
without going back to Proposed Standard status. As a result there would have
to be a truly excellent reason for pursuing this in this wasy rather than by
simply defining some new subtypes with appropriate semantics for your
applications. I have not heard anything even close to such a reason yet.
You are being inconsistent:
Absolutely not. You are proposing that serial/parallel information be moved to
a separate header. I'm opposed to that. Rens is proposing that disposition
information be placed in a separate header. I approve of that. There is no
inconsistency at all in this.
Anyway, I don't like contextual header lines (like Content-ID) either.
I was trying to shift inappropriate information out of multipart
subtype definitions. It's fine with me if we take presentation
information out entirely. But I entered this discussion to point out
that attachments are a presentation issue as well, and we should have a
consistent treatment.
As I have said before, you have not convinced me that serial/parallel
information is purely presentational in nature. It is going to be tough to do
this since I have yet to encounter a single operational case where this
information could in fact be handled in a purely presentational way.
Ned