ietf-822
[Top] [All Lists]

Re: Content-Disposition Header

1993-07-07 12:18:10
To raise a new issue about the document, I think the definitions of the
terms "inline" and "attachment" need to be improved.  There's a
distinction between semantics and user interface which is blurred in the
document, and the semantics of the terms should be more clearly defined.
 I find it helpful to think of ordinary documents when attempting to make
the distinction.  It seems to me that the intended semantics are
approximately as follows, (though I am still having difficulty with
defining inline):

Body parts labeled as inline are intended to be viewed in the same
context, in order.  Body parts labeled as attachments are intended to be
viewed as separate but related entities.   They are distinct from the main
message, but are intended to be referenced from the main viewing area,
just as one would reference an attachment in the main body of an ordinary
document.

Some specific comments which illustrate problems with the current
definitions are below.

From the draft:
A bodypart should be marked 'inline' if it is intended to be displayed
automatically upon display of the message. Inline bodyparts should be
displayed in the order in which they are encountered.
...
Bodyparts can be designated 'attachment' to indicate that they are
separate from the main body of the mail message, and that their
display should not be automatic, but contingent upon some further
action of the user.

So, are sound and video supposed to be called inline or attachments?  What
we often want is for references to them to be placed inline, so that they
can be played from the main body.  (It is not clear whether this would be
considered inline or an attachment.)  However, if we imagine a Word
 document on the Macintosh, we can envision that a QuickTime video might
be
inserted either inline, or as an attachment. (For those who haven't seen
this, this means that you would see a video player with a still image in
the window either in the main part of the document, or at the end of the
document in an attachment, and you could press a play button to play the
video.)  In either case, further user action is required before the video
starts playing.  Requiring further action before playing video was
considered to be desirable by the implementors. This was a user interface
decision entirely separate from the positioning of the body part within
the entire document.  (Similar user interface policies typically apply to
sound.)

Also, a user interface designer might reasonably choose to display
attachments automatically after the inline parts.  It doesn't seem that
automatic display is necessarily an attribute of an inline part but not an
attachment.

Content-Disposition is an optional header; In it's absence, presentation
should default to 'inline'. This is compatible with the behavior of
current MIME-aware user agents.

Not so!! Z-Mail (MIME version under development) displays text
parts inline, also displays them as attachments when there are multiple
text parts, and displays other parts as attachments.  pine displays text
parts inline and displays other parts as attachments.  Andrew Messages
displays parts it can handle inline inline, and displays others using an
inline button, which must be pressed to display the attachment (e.g.
sound). It is not clear how we should describe metamail's behavior using
the terms defined in the document, as it displays body parts in order, but
user action is normally required to view each non-text part.

This policy as defined also requires every MIME implementor to develop
viewers for all MIME types. That seems to be an excessively strong
requirement. Also, it is an impossible one to meet for character-based
interfaces, which simply cannot display multimedia objects like images
inline.

--Carlyn

=========================================================================
Carlyn M. Lowery        lowery(_at_)z-code(_dot_)com    4340 Redwood Hwy, Suite 
B-50
Z-Code Software Corp.   (415) 499-8649       San Rafael, CA  94903




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