I agree. If tightening up the semanatics of multipart/mixed to say that the
parts contained inside are simply a collection of independent things to be
handled in whatever fahsion is appropriate, then I'm all for making such a
change.
Ned, I'm not sure that is clear enough for me; in particular I want
to stop an interoperability problem from cropping up. This started
when Nathaniel's s/w started taking one "logical" document in Andrew
and sending it as a sequence of body parts.
Sun's s/w had a different model: there was a "base" text message
and a sequence of attachments.
I don't see how this relates to the specification of the syntax of
multipart/mixed and multipart/parallel at all. We've basically concluded that
the text+attachments model is sufficiently different from multipart/mixed to
warrant either a new type or a new header. It is therefore not reasonable
to expect clarification of multipart/mixed to provide you with the tool
you need to do text+attachment.
I'm not trying to force anyone to use a different model; all I want is
to be able to tell, from the MIME structure, which model was in use
so I can present things "correctly" to the user.
I *dont* think that loose definitions of multipart/parallel
and multipart/mixed will achieve that. Instead, it will allow
every vendor to implement whatever they want, and interoperability
will suffer (or people will peek at an "X-Vendor" header, and
have their code switch on that (ugh!)).
I agree, but nowhere was it intended that these (minor) clarifications to
multipart/mixed would provide you with a model suitable for text+attachments.
I'm claiming that there are two distinct models of how to use
attachments here -- models that show up to the user.
Part of my problem with multipart/attachment comes from how many models there
are. I see a lot more than two and there's nothing particularly distinct about
any of them.
I think
there has been some consensus on what the models are, and how to
represent them. However, I would like the language to be fairly
tight describing those models, and clear on telling implementors
which headers to use for which model.
There is some consensus that there are some different models here. There is
also some feeling that this text+attachment model is a heavily used data-point.
I see no consensus at all as to whether this is the only additional model
that's needed or how it should be embodied in headers, subtypes, or parameters.
I can live with multipart/attachment. I like the Content-Disposition approach
better, but multipart/attachment would suffice. If we go with
multipart/attachment I would prefer that it do what the label says: it should
only contain attachments without any special first-or-last-is-text rule. And if
we have to have such a rule it simply must be the first part that's special and
not the last.
Finally, about multipart/parallel -- I've *never* understood when
it should be used from the spec; the "model" just was never made
explicit. This strikes me as an unfortunate situation that will
cause problems when people actually start using it, each in a different
way.
You use multipart/parallel when you want to send two or more things that are to
be viewed/converted/whatever simultaneously. This is a _very_ common need, and
I entirely fail to see what's unclear in the specification in this regard. If
you have specific rewording to suggest, suggest away.
Ned