"Neil Durant" <[EMAIL PROTECTED]> wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
> 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?
Hmm, true. But they're still basically the same thing,
just one has a Content-Disposition of "attachment"
and the other of "inline".
> 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),
You can certainly alternate between text sections and
other types in a multipart message.
> 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.
Depends on the Content-Disposition header. If it's "inline",
it's displayed inline, if it's "attachment", it's a separate
attachment. Same as any other type. There is no standard
default behavior (if no Content-Disposition is provided), so
in that case it's up to the user agent.
> 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.
Again, depends on Content-Disposition. That's what that
header is for.
> >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.
I kind of doubt that will happen. There's already text/plain
(in both format=fixed and format=flowed varieties), and
message/rfc822.
