nmh-workers
[Top] [All Lists]

Re: [Nmh-workers] New mhbuild directives

2014-05-14 21:42:21
Lyndon wrote:

How can an inline header specify where to inline the content?  The
point of inline is to display the content in the context of the
location of the inlined MIME part.  I.e. right *here* where I invoke
it.

I don't read that from RFC 2183, just that inline means
"intended to be displayed automatically upon display of the
message" and "presented in the order in which they occur".

So, it makes sense to me that inline text/calendar parts are
automatically fed directly to a calendar program.  I don't
appreciate why gmail handles message/rfc822 attachments the way
it does or doesn't.  Even if we could get it "fixed", I suspect
it won't be the last time we run into something similar.

Back to the "Attach and disposition" subject, I don't want to
lose sight of this:

# it's a shame to have to foist the decision as to which to use
# (Attach or Inline) onto the user.

I, for one, would appreciate if nmh captured the knowledge that
message/rfc822 parts should be sent inline to gmail.  I'm not
sure how other than based on MIME type.  I don't send
message/rfc822 often and would be fine with defaulting it to
inline, but I don't know how others feel about that.

Ken, when you first mentioned "a more generic mechanism", I was
thinking along the lines of
"mhbuild-disposition-<type>/<subtype>: inline" profile entries.
mhn.defaults could provide those for text/calendar and possibly
message/rfc822.  Users could override as they wish in their
profile.

Forcing every nmh user to learn all the exceptions, and remember
them every time they Attach:, is as user unfriendly as we could
get.

David

_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers

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