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
--foo
Content-Type: multipart/mixed; boundary=bar
--bar
Content-Type: image/gif
Content-ID: gif1
Content-Disposition: attachment; filename="gif1.gif"
...
--bar
Content-Type: image/gif
Content-ID: gif2
Content-Disposition: attachment; filename="gif2.gif"
...
--bar
--foo
Content-Type: application/putative-compound-doc
Content-Disposition: inline; requires="gif1,gif2";
filename="mydoc.doc"
....[gif1]......[gif2].....
--foo
Content-Type: application/putative-rtf-doc
Content-Disposition: inline; requires="gif1,gif2";
filename="mydoc.rtf"
....{/include gif1}......{/include gif2}.....
--foo
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.
-Rens