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

[Ken Hornstein]

>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 guess in this scenario I'm trying to think of what the UTF-8 version
would get us, rather than just preserving the original header in the
original character set.  I mean, that's what we do now and it seems
to work fine.

>> 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.

Well, look at how code like pick is structured now.  Actually, my reading
of the code is if you're looking at multiple headers in the same message,
the message gets re-read.  I just think that reading the message off of
disk is the dominant factor at work and given stdio buffering that's
going to be the same whether or not you stop at a particular header.

>> > 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.

Fine with me.

--Ken