lyndon wrote:
kind of by definition. what client MUAs _do_ with those attachments
is a question of semantics. and what gmail did (i.e., nothing) surprised
me.
RFC 2183 is unambigious:
2.1 The Inline Disposition Type
A bodypart should be marked `inline' if it is intended to be
displayed automatically upon display of the message. Inline
bodyparts should be presented in the order in which they occur,
subject to the normal semantics of multipart messages.
2.2 The Attachment Disposition Type
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. The MUA might instead present the user of a
i never said i expected gmail to do something automatically. i would
have been perfectly happy if it had asked me if i wanted to see the
attachment. it's not too big a stretch that it might have -- it was
an *email* attachment, and it an *email* program.
bitmap terminal with an iconic representation of the attachments, or,
on character terminals, with a list of attachments from which the
user could select for viewing or storage.
Well naturally an MUA can do what it bloody well pleases. A well designed
MUA will implement the intent of the underlying standards, in the
interests of interoperability. If MUAs ignore the disposition parameter,
the functionality becomes useless.
au contraire. i can certainly complain, which is what i did.
You can complain, but it doesn't make you right.
i wasn't complaining about about gmail. i was "complaining" about
nmh, by asking what we can do better. again, my apologies.
paul
=----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 58.3 degrees)
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers