[Top] [All Lists]

Content-Disposition Header and multipart/alternative

1993-06-29 10:04:07

On Mon, 28 Jun 93 09:57:12 -0700, Gabe Beged-Dov 
<gabe(_at_)hpcvusd(_dot_)cv(_dot_)hp(_dot_)com> said:

  gabe> I don't know if its simpler but I would try to deal with these
  gabe> type of scenarios using multipart/alternative. It would have
  gabe> two alternatives, the first being the fallback that shows the
  gabe> three gifs, and the second being the compound doc multipart

This is very clever and seems to solve the problem, but I think you
made your example too complicated. If your compound document format
was an application subtype, instead of a multipart subtype, the
structure would not be so arcane:

For Example:

        Content-Type: multipart/alternative; boundary=foo

        Content-Type: multipart/mixed; boundary=bar

        Content-Type: image/gif
        Content-ID: gif1
        Content-Disposition: attachment; filename="gif1.gif"
        Content-Type: image/gif
        Content-ID: gif2
        Content-Disposition: attachment; filename="gif2.gif"
        Content-Type: application/putative-compound-doc
        Content-Disposition: inline; requires="gif1,gif2";

        Content-Type: application/putative-rtf-doc
        Content-Disposition: inline; requires="gif1,gif2";
        ....{/include gif1}......{/include gif2}.....


Note the use of the "requires" parameter to indicate dependencies.

But you basic point about using maultipart alternative is very good.
This would allow us to get rid of the "hidden" type and the "owner".
The requires parameter would still be useful, as I'm sure you see. 

  gabe> content-disposition as part of the external reference since if
  gabe> there are several references to the same part, they should
  gabe> each be able to specify a different presentation state. I also

I envision references to other body parts being made by application
formats that are opaque to the MIME parsing engine. Whatever.

Nathaniel, you raised a point about the hidden disposition type being
difficult to deal with in linear (metamail-style) parsers. Isn't this
also a problem with multipart/alternative, in which the 'richest' of
the alternatives comes last? You have to scan all the alternatives
before falling back to the first, simple one.

This has to be dealt with, it seems to me, whether you use
multipart/alternative or a hidden disposition.

That said, I'd be more than willing to jettison "hidden" in favor of a
reccommendation to use multipart/alternative in this manner. It's a
good clean solution to the problem; good call, Gabe!

Is this agreeable to y'all?

  gabe> I would like to see traceability support decoupled from the
  gabe> presentation state support. The added complexity that mime
  gabe> readers will need to deal with to handle the tracking of
  gabe> boundary conditions doesn't seem justified given the current
  gabe> requirements.

You lost me here. Getting rid of 'owner' simplifies the "traceability
support", but the dependency info in "requires" really helps me out
by letting me pass filenames and/or descriptors to parsing routines.


<Prev in Thread] Current Thread [Next in Thread>