[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-mailutils] Unfolding header value
From: |
Sam Roberts |
Subject: |
Re: [bug-mailutils] Unfolding header value |
Date: |
Thu, 3 Jul 2003 21:57:24 -0400 |
User-agent: |
Mutt/1.4i |
Quoteing address@hidden, on Wed, Jul 02, 2003 at 07:33:18PM +0300:
> > (2) header_get_value() is also used in imap4d etc ... to return header
> > field values.
> > If we fold and collapse headers, how to unfold and unduplicate(see the
> > "Received:" case)
>
> I believe it is not that critical. The newlines may be inserted at
> every whitespace character. For several headers (like Received), we may
> implement the widely accepted ways of folding.
The problem with folding after encoding is, even though it sounds so
sensible, 2 things happen:
1 - you can't fold at whitespace in a qstring, so you have to be a
tiny bit careful
2 - for reasons I don't understand RFC2822 tries to suggest (SHOULD)
only folding at places that look nice. Whats the point of that? You have
to know the syntax of a field, and decode it, in order to fold it as
they suggest? If you do this, you might as well generate the folding at
the time that you create the field value, because you know its structure
there. This breaks the suggested RFC822 model, where folding is a simple
thing you can do before or after, without respect to the type of the
field.
But, people still have to accept the "obsolete" RFC822 syntax, so, I
think its still completely reasonable to just fold at whitespace, as
long as you avoid quoted strings. I don't think you can \ escape
whitespace outside of a qstring, can you? If so, you'd have to look out
for that, too.
I think the fastest unfold algorithm, for the original poster, is just
copy the value, considering SPC, TAB, CR, and NL to be whitespace, and
concatenate runs of extra whitespace into a single SPC. Should look
fine when displayed.
Cheers,
Sam