Re: Content-Disposition ancillary

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