[Top] [All Lists]

Re: C-D: Attachment Clarification

1995-01-19 15:08:20
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 
MIME spec.

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 
     encapsulation boundary.

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.


<Prev in Thread] Current Thread [Next in Thread>