>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 [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
