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

[Ralph Corderoy]

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.