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
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers