The experiences of another major mail system (AT&T Mail) which provides for
attachments of this nature indicate that the proper place for the main
message is at the beginning of the message and not at the end. You normally
attach an item to something. In order to do that attaching, you first have
to have that something. So you provide the something first so you can do the
attaching.
Definitely.
Here's my 2 cents on this debate. I did send these ideas to Nathaniel, but
he's pretty busy lately, so I'll repeat them.
I see two possible content types that could be used to resolve this issue
of attachments:
multipart/attachments
message/attachment
The first is pretty obvious: it indicates 1 or more attachments to the
surrounding message. Typical usage would be something like:
Content-Type: multipart/mixed; boundary=abc
--abc
Content-Type: text/plain
... blah, blah, blah: main message ...
--abc
Content-Type: image/gif
Content-Transfer-Encoding: base64
[data for an inline image in the message]
--abc
Content-Type: multipart/attachments; boundary=defg
--defg
Content-Type: ...
[data for the first attachment]
--defg
Content-Type: ...
[data for the second attachment]
--defg--
--abc--
The big advantage of this IMHO is that all attachments can be kept together
in a block and easily identified.
The second form (message/attachment) would be used something like:
Content-Type: multipart/mixed; boundary=abc
--abc
Content-Type: text/plain
... blah, blah, blah: main message ...
--abc
Content-Type: image/gif
Content-Transfer-Encoding: base64
[data for an inline image in the message]
--abc
Content-Type: message/attachment
Content-Type: ...
[data for the first attachment]
--abc
Content-Type: message/attachment
Content-Type: ...
[data for the second attachment]
--abc--
The advantage of this form is that the attachments are at the same level as
the main message, but there will probably be some craziness with nested
transfer encodings. I prefer the first form at present.
Just some ideas. Whether it is prudent to add either or both of these to
the next MIME spec is up to the authors ...
Cheers,
Rhys.