"Chris" == Chris Newman <chrisn+(_at_)CMU(_dot_)EDU> writes:
Chris> The "inline" content disposition has more semantics than what
Chris> is implicit to the CID URL.
Chris> How about a content disposition of "embedded", since the part
Chris> (when properly displayed) is embedded within the view of a
Chris> different part.
This was the original purpose of the 'hidden' disposition type, which
was dropped from the current C-D spec. Embedded is a better name; I
like it. Perhaps we should IANA-register it one C-D goes RFC.
Chris> Of course, this leads to the question of what to do with an
Chris> embedded part if one hasn't yet seen the part it is embedded
Chris> within.
Exactly the problem that made us take out the 'hidden' disposition
type. I had a parameter that identified the enclosing/organizing
content-id as a way of dealing with this, but that created an
unfortunate many-to-one relationship between subsidiary and primary
bodyparts; you may want to have multiple primary bodyparts (text
vs. graphical version, for example) organizing the same subsidiaries.
Chris> Perhaps a simpler and better approach would be to have a new
Chris> multipart type, say "multipart/embedded", where the first
Chris> part is a hypermedia format (e.g. text/html) with references
Chris> to the other parts. The display hint is that if the first
Chris> part can be fully interpreted, the other parts should be
Chris> skipped. It could also be a hint that the other parts are
Chris> not particularly useful by themselves (e.g. lots of little
This is not a bad approach; you should still label the subsidiary
parts with attachment or embedded dispositions for compatibility with
past and future clients that do not support your scheme, though;
otherwise, they'll default to treating it as multipart/mixed and
display a confusing array of, as you say, red dots!
-Rens