From: Ned Freed <NED(_at_)sigurd(_dot_)innosoft(_dot_)com>
Subject: RE: file attachments in MIME
To: Bill Janssen <janssen(_at_)parc(_dot_)xerox(_dot_)com>
Multipart/parallel (meaning simply ``here're a bunch of parts'') and
multipart/alternative seem to have reasonable semantics, though.
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'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'm claiming that there are two distinct models of how to use
attachments here -- models that show up to the user. 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.
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.
Neil