"Jacob" == Jacob Palme <jpalme(_at_)dsv(_dot_)su(_dot_)se> writes:
Jacob> On Mon, 15 May 1995, Rens Troost wrote:
Keith> The 'name' parameter should be replaced by the filename
Keith> parameter of the Content-Disposition body part header.
>> Indeed. You might also want to use the content-disposition
>> header to make your html bodypart 'inline' and any subsidiary
>> bodyparts (gifs, sound) 'attachment' if you plan to reference
>> them via content-id URNs or similar mechanism.
Jacob> Is this not handled by the CID: URL combined with a
Jacob> Content-ID header on the subsidiary bodypart? Or is there
Jacob> also a need to have a special kind of content-disposition on
If you label your subsidiary bodyparts as 'attachment', the reader has
a hint not to display those bodyparts as part of reading the mail
messgae; that way, they only get displayed in vonjunction with the
display of the html bodypart that references/organizes them.
Jacob> the subsidiary bodypart? Is "inline" a planned value of the
Jacob> content-disposition header?
Indeed; the RFC will define 'inline' and 'attachment' and allow
extension. Check out draft-dorner-content-header-02.txt in your local
internet-drafts cache. Originally I had envisioned a third disposition
type of 'hidden' precisely for use with subsidiary bodyparts. This was
dropped from the spec because compound documents were not fully baked
yet, and because it raises issues of how to recover from a situation
where the primary bodypart cannot be displayed. You could perhaps
achieve the same results with a special multipart geared for compound
docs, as well, but I'm averse to complex multiparts to solve
presentation-disposition issues.
-Rens