Hi Ken,
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.
And UTF-8 internally would give a third option. For a header, are three
things wanted: the raw header, embedded linefeeds and all; a logical
single-line version but with the =?ISO-8859-1? still present; and a
decoded UTF-8 version of the previous.
`subject' could go from the last of those three back to an encoding for
the US-ASCII's user's draft, if strictly necessary. (Some MUAs seem to
just put plain ASCII unnecessarily in an =?ISO-8859-1? these days.) That
the user never sees the finesse of the subject on his teletype shouldn't
stop him replying to the mailing list without changing the subject to
US-ASCII.
I'm just thinking in terms of code complexity; readers would have to
indicate that they want to stop parsing at a particular header.
Wouldn't readers ask for the headers they wanted. Either just asking
once, e.g. `subject', or for the next one, e.g. `received', from where
they left off. Passing in a special value gets every header, one at a
time, in the order they're in the header.
That might be more work than I want to invest in the new API.
Yep, sure.
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.
Now I've seen it is, I've completely flipped my view. :-) One of nmh's
strengths should be its claim to RFC compliance.
Cheers, Ralph.
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers