Further, this has NOTHING to do with the message structure, as you
imply. It has to do with the text's internal structure. The idea that
separate objects are always displayed on separate lines reflects the
implementation structure some systems, but not all of them, and reflects
nothing at all abut the structure of a multipart message. If what I get
is a multipart containing non-newline-terminated text followed by an
image, I'm just displaying it as such. It seems to me it would be a
mistake to ADD a newline between them if I don't absolutely have to for
implementation reasons!
I'm not sure this discussion is going anywhere, but everyone love's an
argument...
I made several points, which I don't think you've addressed:
1. Separate systems are allowed to display things in different ways.
Therefore,
in some sense this issue is unimportant. However, to the extent we have
common understanding of these issues, we improve interoperability. Whether
something shows up on the same line *could* impact meaning.
2. Your interpretation is implying that all the multipart/mixed objects are
embedded
in a text fabric. However, nothing in the MIME spec discusses this. The
discussion
of where a body part *really* ends is simply being precise about exactly
what
data is included in the body part--or at least that's how it reads.
3. This "interpretation" of the impact of a text object ending or not ending
with
a CRLF is insufficient to achieve true inline objects. It only works for
text and
requires additional structuring information to be included if a generating
application
wants to get a "Slate-type" effect (i.e, the default interpretation is a
separate object
acts like a separate paragraph). As Keith pointed out, inline objects also
can
require additional information (like baselines and scaling) in order to
truly do
them right. This is an issue to be addressed by the semantics of the
enclosing
type and hasn't been addressed by the "trailing newline" rule.
You say "it seems to me it would be a mistake to ADD a newline between them".
This is a very Andrew-centric view of the world. Nothing wrong with this view,
but
its not everyone's view and it is not a priori better than another view.
To summarize, I believe it would be useful if we had agreement on this point,
I think the "inline interpretation" has significantly more far-reaching
implications
than you realize (since these implications are natural in an Andrew setting) and
that these implications have in no way been specified and would require
significant
additional machinery to specify. Therefore, I think it makes sense to not take
the "inline interpretation" (i.e. ignore that missing newline).
Finally, Slate can indeed do inline objects, it's just not the normal way it is
handled when the user adds new objects to a document.
Terry