Garth Wallace <[EMAIL PROTECTED]> writes
>> By all means force outgoing attachments to be put at the end by the
>> software, if preferred, but mail/news clients should be able to
>> interleave body text and attachments for incoming messages if they are
>> to comply with the RFCs.
>
>It's called an "inline attachment". There's an optional
>MIME header "Content-Disposition:" that is used to
>determine whether the content should be displayed
>inline with the basic message view or separately as
>an attachment.
>
>From RFC 2183:
>
>> 2.1 The Inline Disposition Type
>>
>> A bodypart should be marked `inline' if it is
>> intended to be displayed automatically upon display
>> of the message. Inline bodyparts should be presented
>> in the order in which they occur, subject to the normal
>> semantics of multipart messages.
>
>Note that last sentence. Mailers that ignore the
>Content-Disposition header display text following the inline
>attachment as attachments because they really are
>attachments...they're separate from the initial main body
>text. The inline attachments aren't "interleaved with the
>main body text", they follow the main body text and can
>be themselves followed by additional inline attachments
>(which may be text).
>
>And for completeness' sake:
>
>> 2.2 The Attachment Disposition Type
>>
>> Bodyparts can be designated `attachment' to indicate
>> that they are separate from the main body of the mail
>> message, and that their display should not be
>> automatic, but contingent upon some further action of
>> the user. The MUA might instead present the user of a
>> bitmap terminal with an iconic representation of the
>> attachments, or, on character terminals, with a list of
>> attachments from which the user could select for viewing
>> or storage.
But doesn't this suggest that the term "attachment" really really
refers to part of a MIME message that shouldn't be "displayed" (in
whatever appropriate sense) within the message? For example, a JPEG as
an attachment that isn't expanded into a visible image inline, but
appearing as perhaps an icon that can be clicked on to launch a separate
viewer?
Nothing in the RFCs, as far as I can see, suggests that a multipart
message cannot have interleaved text and "attachments" (whether they are
perhaps images rendered inline, according to the content disposition
header, or some other visible representation of the content), and I
don't see why the content disposition header is relevant to anything
other than how viewable MIME content is displayed. Surely if part of a
multipart message is "Content-Type: text/plain", it should be arguably
be displayed as text, and not shown to be an attachment.
In particular, if you send a multipart message of the form:
Paragraph of text
## (this is some attachment)
Paragraph of text
..then the 2nd paragraph of text should appear in exactly the same form
in the message (in raw form) than the first paragraph, so it's no more
likely to be intended to be a text attachment than the first paragraph,
which is generally shown as text.
>Unfortunately, none of the RFCs really address sigs in the
>context of MIME format: they don't say whether sigs must
>appear at the end of the main body text, or if they may
>appear in inline attachments, so you have to go by how the
>majority of mailers/newsreaders interpret it. In my experience,
>the sig tends to get put in the first section of the body (main
>body text) and attachments follow. That also seems to be safe
>(that is, I haven't seen a mailer strip an inline text attachment
>because it follows a sigdash in the main body).
>
>Son-of-RFC 1036 mentions that work is being done on a MIME
>based signature scheme (a note in section 4.3.2):
>
>> NOTE: The choice of delimiter is somewhat unfortunate,
>> since it relies on preservation of trailing white space, but
>> it is too wellestablished to change. There is work underway
>> to define a more sophisticated signature scheme as part of
>> MIME, and this will presumably supersede the current
>> convention in due time.
>
>Hopefully this MIME-based sig standard, if it ever appears,
>will clear up the ambiguities sigs have WRT attachments.
Indeed. In addition, maybe it would be beneficial to have quoted text
appear as a separate MIME type.
Neil
--
===================================================================
Neil Durant
<[EMAIL PROTECTED]> Fax: 08700 520159
===================================================================
