re: Mixing text and graphics with text/enriched and multipart/mixed

[Terry Crowley <[e-mail]>]

>> The only currently "standard" way of mixing rich text and graphics in MIME
>> that I know of is to use an enclosing multipart/mixed containing
>> text/enriched and image/* body parts.  However, since each text/enriched
>> part needs to be complete in itself, we need to terminate the <<center>
>> directive before adding each image/* part.  This, in turn, means that
>> we'll be forcing a newline to be displayed on the receiving end next to
>> each <<center> or <</center>.

I discovered this problem three or four years ago.  As Nathaniel pointed out,
the original MIME spec was indeed careful about being able to generate body
parts (specifically text/richtext) that did not end in CRLF.  Some interpreters
(e.g Andrew) then interpreted this to mean that the following object should
appear on the same line.  However, the clarifications made when text/enriched
was written to more carefully specify line breaking issues around alignment
directives apparently broke this in the example you are giving.

However, the more important issue is that multipart/mixed places no concrete
requirements on the layout of the individual parts, certainly not to the
details of how a missing or present CRLF on one object should change the way
the following object is layed out.  It was reasonably clearly understood at the
time MIME was written that the proper way to handle this was to have one
representation (e.g HTML) that specifies the relationship of a set of objects
and then use multipart/mixed (or some other multipart subtype) as the way of
packaging those objects.

If someone desired to enhance text/enriched to provide the necessary control
you want, the proper way of achieving this would be to support references
within the text/enriched to other objects (e.g. by Content-ID) in a containing
multipart/mixed object.  Or to have some new multipart subtype that explicitly
requires text/enriched as the first object followed by any referenced objects
(one could make the argument that this more clearly reflects the semantics).

Terry