At 2:34 AM 1/19/95, Terry Crowley wrote:
the MIME spec. This particular one had a lot of implied semantics
matched Andrew's document model but was never stated explicitly in
If we're talking about the same thing, it *is* stated explicitly.
NOTE: The CRLF preceding the encapsulation line is conceptually
attached to the boundary so that it is possible to have a part
that does not end with a CRLF (line break). Body parts that
be considered to end with line breaks, therefore, must have two
CRLFs preceding the encapsulation line, the first of which is
of the preceding body part, and the second of which is part of
Steve Dorner, Qualcomm Incorporated. "Oog make mission statement."
The spec is indeed clear about whether the previous body part should
end or not end with a CRLF. What is not clear is whether the fact that
it DOES NOT end with a CRLF should imply anything about how the
following object should be presented in relation to it. The biggest
issue is that if your document model is a text flow with (possibly
hierarchically) embedded objects (as the Andrew model is) then what
I've probably unfairly called a "hack" falls out as the proper
semantics. If your model is a general hierarchical tree of objects,
then whether one of these objects, a text paragraph, does or does not
end in a CRLF, says nothing about how the next object should be
displayed in relation to it. You need additional presentation
information that can't be specified in MIME.
As you start getting into this, you find that it may be possible to
define some reasonable semantics, but those semantics are not universal
and therefore will be appropriate for some systems but inappropriate
for others. It's basically a can of worms, better left to a real
compound document format. The big win is probably going to be the work
to extend the URL syntax to be able to specify other objects in the
current message. That way you can use HTML as your compound document
format and have it refer to other objects in the message with a
well-defined presentation semantics.