On Wed, Aug 12, 2015 at 8:55 PM, Ken Hornstein wrote:
- Handle everything internally as UTF-8.
- For _display_, try to convert all of the characters to the native
character set (yes, using the locale, dammit!).
- For things like _replies_, if we are not in an UTF-8 locale then
downgrade things like the addresses using RFC 6587 rules (well, the
subject as well ... I think the way it would work is the format
engine would do the encoding for you behind the scenes for all
components).
- Reconvert such messages to 'canonical' standard while sending. Well, I
think just for addresses; leaving everything else as an encoded word might
not be harmful. But I'd have to think about it.
- But this also makes it clear that the thoughts of having an 'external'
decoder stage will simply not work; you need to know too much about each
header, because they're all handled differently.
Sorry for late reply...
The above looks reasonable to me.
The 'external' encoder/decoder is more of a pie-in-the-sky idea of
allowing the encoder system being abstracted so one could plug in
different engines if needed. Basically, using pipes into and out of it
whenever an encoding/decoding operation is required.
However, if the level of effort to achieve such an abstraction is not
worth any potential benefit, do not bother with it.
Note, there may be some benefit in providing some level of abstraction
for the encoder if there is a concern of nmh getting locked-in code-wise
to a specific library.
--ewh
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers