[Gnubiff-devel] Re: [Gnubiff-bugs] Bug in unfolding of headers

[Samuel H. <sam...@gm...>]

Hi Robert,

Thank you for your fast answer!

> > Subject: =3D?iso-8859-1?Q?s=3DE9anc?=3D
> > =3D?iso-8859-1?Q?e?=3D du 21/04/2005 (bonne date)
> Probably there should be a whitespace character at the beginning of the
> second line, otherwise there is no folding and this line would be an
> invalid header line.

Ok, I'll try to be careful next time. The fault comes from the new
gmail editor which decided that the spaces should be kept only in the
html alternative of the message and removed them from the plain
text... There is indeed some space in the beginning of the line.
=20
> > gnubiff displays =AB s=E9anc e du 21/04/2005 (bonne date) =BB whereas t=
he
> > space at  the beginning of the line is just part of the folding
> > process, not the  subject.
> I think you expect "s=E9ance" instead of "s=E9anc e"? (sorry, I don't spe=
ak
> French(?))

Yes, exactly.=20

> According to the standard (see RFC 2822 section 2.2.3.; see below)
> folding line breaks may only occur just before (certain) white space
> characters. When unfolding only the line break has to be removed not the
> white space. So (if I understand your example correctly) your subject
> line is treated correctly (but this line itself is buggy).

Ok, my remark was not proper. I indeed thought the bug was in
unfolding as such. But in the fact the trouble comes from MIME
encoding of the header. And I finally found the specification that
corresponds to the subject I gave. In RFC 2047, page 10, it reads:

    When displaying a particular header field that contains multiple
   'encoded-word's, any 'linear-white-space' that separates a pair of
   adjacent 'encoded-word's is ignored.  (This is to allow the use of
   multiple 'encoded-word's to represent long strings of unencoded text,
   without having to separate 'encoded-word's where spaces occur in the
   unencoded text.)

Without this specification it would be impossible to fit any given
text into RFC 2822.

Cheers
Sam