To: ietf-822(_at_)dimacs(_dot_)rutgers(_dot_)edu
Subject: Re: text/enriched
Date: Fri, 13 Aug 1993 13:54:30 -0400 (EDT)
If the existing way of mixing different formats in MIME doesn't do
quite what you want that's not a reason to create a completely new
mechanism to mix formats. Why not just improve the existing mechanism?
You could, for example, create a "multipart/contiguous" subtype that
means the parts should be displayed contiguously. That would do what
you want, [...]
No it wouldn't. In particular it wouldn't allow me to describe where on the
screen a particular body part should be displayed, how big it should be, when
to go to a new page. Putting such extensions into a new multipart type would
require major changes to the MIME model.
However, my point was that the MIME spec does not guarantee that a sequence
of text/enriched, text/plain, and text/enriched will be treated in the same
way as a <verbatim> section in text/enriched.
Perhaps the verbatim feature of text/enriched needs some tweaking, but I
think some such feature is needed.
I don't think a "feature" that creates a mechanism to embed text/plain
in text/enriched is a good idea. You shouldn't have to parse each
section of a MIME message to find out what different types are in it.
Actually, I sympathize with the view that there shouldn't be an escape
mechanism inside text/enriched that says "treat everything as plain text
until the next </verbatim>". I still need to be able to specify that a
certain block of text be displayed exactly so, with no filling, justifying,
or indent. But I can live with having to encode certain characters (like
less-than) within that environment.
Keith