On Thu, 8 Apr 1999, Harald Tveit Alvestrand wrote:
I still think that content-disposition is an inferior approach to
those based on multipart/related; the disposition is part of a bodypart's
context, not part of the bodypart itself.
I really think they're solving two different problems.
multipart/related, multipart/appledouble, multipart/report,
multipart/signed and their ilk all create a "context" which takes
precedence over the Content-Disposition header iff the receiving client is
aware of the semantics of the multipart (which in the case of
multipart/related includes the semantics of the start body part).
Content-Disposition in general and ancillary in particular are the
fallback position if the receiving client doesn't understand the multipart
context (or if it's multipart/mixed, so there's no semantics in the
multipart context).
It might be appropriate to add some discussion along these lines to the
next revision of the Content-Disposition spec.
I want to see ancillary put on things like vcards, ms-tnef and similar
cruft so clients know to make them unobtrusive. But it also has value
when the next multipart/foo is introduced and clients aren't familiar with
it, or when the new application/whizbang type is used as the base for
multipart/related.
But I recognize that this battle is lost, and support moving ahead with
this specification; in our current situation, this is the useful thing to do.
I'm not sure I recognize a battle. They seem like complimentary services
to me.
- Chris