Another idea to throw into this thread would be RFC 2387 on the
text/x-okie MIME type, which seem to be a solution to this problem.
It's only used as an example in the RFC, and I do not know if anything
became of the text/x-okie idea, but it shows that others has
considered this to be a problem worth solving before.
5.2 Text/X-Okie
The Text/X-Okie is an invented markup language permitting the
inclusion of images with text. A feature of this example is the
inclusion of two additional body parts, both picture. They are
referred to internally by the encapsulated document via each
picture's body part content-ID. Usage of "cid:", as in this example,
may be useful for a variety of compound objects. It is not, however,
a part of the Multipart/Related specification.
Content-Type: Multipart/Related; boundary=example-2;
start="<950118(_dot_)AEBH(_at_)XIson(_dot_)com>"
type="Text/x-Okie"
--example-2
Content-Type: Text/x-Okie; charset=iso-8859-1;
declaration="<950118(_dot_)AEB0(_at_)XIson(_dot_)com>"
Content-ID: <950118(_dot_)AEBH(_at_)XIson(_dot_)com>
Content-Description: Document
{doc}
This picture was taken by an automatic camera mounted ...
{image file=cid:950118.AECB@XIson.com}
{para}
Now this is an enlargement of the area ...
{image file=cid:950118:AFDH(_at_)XIson(_dot_)com}
{/doc}
--example-2
Content-Type: image/jpeg
Content-ID: <950118(_dot_)AFDH(_at_)XIson(_dot_)com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture A
[encoded jpeg image]
--example-2
Content-Type: image/jpeg
Content-ID: <950118(_dot_)AECB(_at_)XIson(_dot_)com>
Content-Transfer-Encoding: BASE64
Content-Description: Picture B
[encoded jpeg image]
--example-2--