ietf-822
[Top] [All Lists]

Re: C-D: Attachment Clarification

1995-01-18 09:23:31
< I would suggest that you have shown the need for a new type of attachment:
<
< content-disposition: attachment-represented-by-inline-icon
<
< Let's do that as a registered disposition type once the basic
< content-disposition is out of the door.

Not at all; whether something which is inline is presented as an icon or
presented as that thing itself is a function of the user agent presenting
the message. Some things are naturally represented as that thing itself,
others could be icons, and still others could be some sort of tool that
appears inline. Consider an inline audio segment: I could easily see one
user agent presenting it as an icon, while another user agent presents it as
a little audio player control, while another user agent indicates with words
that an inline audio segment is present and how to listen to it. All of
these are reasonable "representations" of that inline audio segment.

Now, consider an audio segment marked as an attachment: I could easily see
one user agent presenting a list of icons at the end of the message
indicating the attachments, while another user agent presents a hierarchical
tree of attachments somewhere else on the screen, while another user agent
presents a button saying "view attachments", etc.

So why would you need something like "attachment-represented-by-inline-icon"?
The iconization of that segment is purely a matter of presentation.

                                        Tony Hansen
                            hansen(_at_)pegasus(_dot_)att(_dot_)com, 
tony(_at_)attmail(_dot_)com
                                att!pegasus!hansen, attmail!tony