Re: [Nmh-workers] nmh internals: full MIME integration

[Ken Hornstein]

>> Well, to whatever the local character set is.
>
>Ah, OK, my natural inclination is UTF-8 everywhere and convert on I/O,
>but we've obviously got a backlog of code to consider.

It's not even that ... consider the existing APIs.  If we consider iconv(3)
to be a required dependency (something I'm seriously considering) then it's
not so bad.  But ... I guess I don't see the gain converting everything
internally to UTF-8; you're still converting it to the local character set
in most cases.

>If the new
>header handler is "to local character set", e.g. US-ASCII, then how does
>replying to an email with a =?utf-8? subject work?  Does it suffer
>lossage as it's ASCII'd before an inferior version reaches the `Subject:
>Re:' producer?

Well, I guess we could make it work both ways.  Right now it's not really
decoded before it hits the format engine.  We could keep with that logic.
Or if you wanted to convert it to ASCII ... well, I don't see a better
option than converting it and substituting an appropriate character.

>Neither was I.  :-)  Most programs that want headers don't want all
>headers?  Some want relatively few out of the many that are stuffed in
>there nowadays.  It's a bit hard to think of ones that do want them all
>with the normal components file?

Well, most people don't care about the Received headers, that's for sure.
I'm just thinking in terms of code complexity; readers would have to indicate
that they want to stop parsing at a particular header.  That might be more
work than I want to invest in the new API.  But like I said, if it turns
out that performance of the tools noticably suffers then I'm willing to
revisit it.

>So I vote to drop support for these kind of invalid headers unless
>anyone here has some that show they're common?

My gut says to go with you ... but it is technically a RFC 5322 violation.
I'd need to think about it some more.

--Ken