Re: [Nmh-workers] Maybe time for a new release?

[Ken Hornstein]

>No, that's not true. We could decode on inc(1) to UTF-8. Every other MUA
>(effectively) does that these days.

Sigh.  That doesn't help with image/jpeg, video/mpeg, application/pdf ...
all of those things which are not text.  That's really my point.  It
doesn't even really help that much with text/html.  And converting to
UTF-8 is only a win _if_ your local character set is UTF-8.  We have
plenty of people for whom it is not.  And I honestly do not believe that
other MUAs convert to UTF-8 upon incorporation; from what I've seen, they
store them internally in the on-the-wire format.

>Yes, I have argued for and against this in the past, specifically
>against the crypto-signature-breakage.  But really, what are the odds?
>I would rather we decode all the MIME-encoding crap, and wherever
>possible, translate text/* to utf-8 according to the charset parameter
>indications in the mime part.  This means grep(1) continues to work.

I think changing the message store to not be RFC-5322-format files is a)
unfriendly (since that's been the assumption by all of the MH/nmh tools
and their frontends since forever), and b) will have lots of unintended
consequences.  From where I'm sitting it's a poor tradeoff just to make
grep(1) work (and saying that grep(1) 'continues' to work is ... not
accurate; I do not believe you can say that it works today).  And I can
say that for me, at least, the issue of crypto-signatures breaking is
not a theoretical concern; I have a need for S/MIME support, and that's
something I was planning on working on.

If the goal is to get grep(1) working, like I said, I'm fine with some
of the schemes proposed where there is an ancillary set of files that
are Unix text format.

--Ken