I like this model a lot. I had originally envisioned this as a parameter on
the
Content-Type line, but when you get right down to it this has nothing to do
with the type of the contents; it is instead an indication of how the
content,
regardless of type, should be handled. It therefore makes a lot of sense to
handle this as a separate entity.
I agree, but the principle that Content-type should not involve
presentation reflects badly on the definitions of multipart/mixed and
multipart/parallel. That is, mixed means display serially and
parallel means display simultaneously, according to the spec.
If the notion of serial/parallel referred to positioning on the screen I would
agree with you -- this information would have no business being either a
subtype or a type parameter. However, it does not refer to this -- as you say,
it refers to how the contents are to be interpreted temporally. Any
characterization of the "temporal position" of the parts as some sort of
generic attribute would imply that this could apply to any type and not just
multipart. It does not generalize in this way (not even to messages), so while
I see where you're coming from on this I don't find your argument pursuasive.
The subtypes of multipart are there to tell your code how to interpret the
contents, just like any other subtype.
This also brings up the issue how how screen positions actually would be
specified in MIME. Given that this information is specific to certain types, to
say nothing of the fact that the specifics of the information are likely to be
type-specific, I don't see it as part of some kind of generic disposition
information. (Audio in particular is hard to position, although I suppose a
sufficiently generic positioning scheme could be seen as a kind of "balance
control"...) On the other hand, this stuff definitely falls into the "hints"
category. However, I don't have strong feelings about this. For that matter, I
don't know if anyone really cares about positioning information in MIME.
(Counterexample: Novell MHS goes to great lengths to provide positioning
information for header lines and whatnot, so I guess some systems actually do
care about this stuff.)
By the way, this reminds me of an argument I had once regarding the
meaning of the spec's use of "displayed serially". A colleague contended
that it meant geometrically, i.e. going down a page if presented as a
document; I contended it meant a temporal series. Obviously I had the
right original intent :-), but maybe it could use a little clarification?
From RFC1341:
data in multiple formats, "parallel" for parts
intended to be viewed simultaneously, and "digest"
for multipart entities in which each part is of
type "message".
Later sections reiterate this point, using similar terminology.
I don't see how the term "simultaneously" could be taken to imply something
geometrical. I therefore don't think this needs to be clarified -- if it does I
sure don't see how or why.
Ned