Re: [Nmh-workers] iCalendar support

[Ken Hornstein]

My apologies for the delay ... been busy, wanted to give this some thought.

>repl would need to determine the correct charset parameter and
>C-T-E, and would also need to check that there was exactly one
>iCalendar request in the message being replied to.  I'm not sure
>what to do if there's more than one.  I have yet to receive such
>a message, so my inclination is to punt.  The user could instead
>extract and reply to each request by itself.  Or, repl could
>reply to each one the same way.  I don't think it's worth
>complicating the interface to support different replies to
>multiple requests in a message.

Some meta-thoughts:

- What were your thoughts in terms of what the interface would look like
  at the "repl" level?  Just a new switch?  Did you want to make it more
  generic?

- What were you thinking in terms of implementation details?  Yes, I
  understand about the mhical utility, but I was thinking of what
  you'd need in all of the other tools to make it work.

- Are you sure you want to have a mhbuild directive in the reply?

The last question is actually the most interesting one.  We're trying to
grapple with the larger meta-question on how to better handle MIME.  I
think for the tools that display or process message content we have a
reasonable handle on what needs to be done.  Sure, there's a lot of work
that needs to be done there, but I don't think any of it is particularly
controversial.

Composing a new message is a bit more complicated, but I think with the
update to the attachment system we have a reasonable thing in place.
There are implementation warts, but those should easily be fixable.
This handles the 95% case where we want text content followed by one
or more non-text parts.  For people who want to have complete control
over their MIME content, mhbuild directives are still available.  But
I've been using the Attach: headers recently and they are very nice;
I'm happy how that worked out and the new implementation feels much
more like the "MH way", in that headers are used to control message
processing.  If people disagree with this, I'd like to hear about it and
your suggestions for a better composition interface.

Now, replying to a message is kind of an unholy combination of
displaying and composition.  We've never really figured out how to
bridge the gap here very well.  To be fair, nobody else seems to handle
this really well either; a few things are special-cased in MUAs (like
calendar requests, although in my experience what happens there is that
you have to do something at message display time) but mostly they don't
deal with non-text parts for replies.  Maybe we should do better!  

The question is ... what do we do?  A general thought is that we
shouldn't have nmh commands output mhbuild directives into drafts.  That
just seems like the wrong approach; it gives special meaning to the
message body and it requires the user to know to run the "mime" command
at the WhatNow? prompt.  The more I use it, the more I think the attach
command's general interface is more reasonable; headers already have
special meaning, we have a specialized tool to manipulate them (anno)
and it seems to work out well in practice.  People will point out that
some MH commands already emit mhbuild directives, but I view that as a
wart that shouldn't be repeated.  Specifically, if you run "forw -mime",
instead of a message that contains:

#forw +inbox 8 22

You should probably have a message that has a header like this:

Forward: +inbox 8 22

Or, maybe, something else; that's just an off-the-cuff idea.

So it occurs to me that maybe we should have some mechanism to allow
repl to insert generic headers into the reply draft that mhbuild could
later process.  The devil really is in the details there, though; the
mechanics of that would have to be carefully thought out.

--Ken