unless there is some way to tell if a hidden bodypart is displayed
somewhere, we are faced with possibility of the following scenario:
a user recieves a message with three hidden GIF images and a
compound document bodypart to organize their display. The users MUA
does not grok the document format, but could easily display the
GIFs. unfortunately, since they are hidden and there is no way of
knowing that their owner is not being displayed, the user does not
get to see them.
This is the scenario that 'owner' was designed to avoid. I cannot
think of any simpler way to do this, but remain completely open to
suggestions.
I don't know if its simpler but I would try to deal with these type of
scenarios using multipart/alternative. It would have two alternatives,
the first being the fallback that shows the three gifs, and the second
being the compound doc multipart that presents the gifs as hidden. I
have used an intra-message form of message/external-body in order to
have multiple references to the gifs. I have also included the
content-disposition as part of the external reference since if there
are several references to the same part, they should each be able to
specify a different presentation state. I also placed the actual parts
at the start of the message so that processing can be done in one
pass. Here's the example:
content-type:multipart/alternative;boundary=111
--111
content-type:multipart/mixed;boundary=000
--000
content-type:image/gif
content-id:gif1
gif data ............
--000
content-type:image/gif
content-id:gif2
gif data ............
--000
content-type:image/gif
content-id:gif3
gif data ............
--000--
--111
content-type:multipart/fooDoc;boundary=222
--222
content-type:application/foodocDisplay
instructions on how to handle the gifs...
--222
content-type:message/external-body;access-type=local
content-type:image/gif
content-id:gif1
content-disposition:hidden
--222
content-type:message/external-body;access-type=local
content-type:image/gif
content-id:gif2
content-disposition:hidden
--222
content-type:message/external-body;access-type=local
content-type:image/gif
content-id:gif3
content-disposition:hidden
--222--
--111--
As to the 'requires' parameter, it is meant as an aid to implementors,
so they can open file descriptors, retrieve from a bodypart server,
or whatever prior to parsing a bodypart that will require other
bodyparts. I think is is a convenience, but by no means necessary.
I would like to see traceability support decoupled from the
presentation state support. The added complexity that mime readers
will need to deal with to handle the tracking of boundary conditions
doesn't seem justified given the current requirements.
-Rens
Gabe