On Fri, 2005-07-01 at 17:58 -0700, Philip Guenther wrote:
Works for me. 2.4.2.2 now reads: [...]
Folding of long header lines (as described in [IMAIL] 2.2.3) is
removed prior to interpretation of the data. The folding syntax (the
CRLF that ends a line plus any leading whitespace at the beginning of
the next line that indicates folding) are interpreted as if they were
a single space.
<pause>
Hmmm, that last paragraph actually differs from RFC 2822, section 2.2.3,
which says:
Unfolding is accomplished by simply removing any CRLF
that is immediately followed by WSP.
I.e., the leading whitespace should *not* be treated as a single space
but rather be left as is. Unless I hear screams, I'm going to remove
the sentence that starts "The folding syntax..." as conflicting.
that's fine, but I find it a bit misleading to only refer to [IMAIL],
since RFC 2047 changes the folding rule in the presence of two
encoded-words: any folding whitespace between them must be removed (see
section 6.2 paragraph 3).
Er, no. RFC 2047 makes no changes to how header fields are folded or
unfolded. Indeed, the word "fold" appears nowhere in RFC 2047.
What RFC 2047 does is state that white space between encoded words should
be ignored when displaying. That's a VERY different thing from changing
the unfolding rule to call for space to be removed entirely under some
circumstances.
e.g.,
Subject: =?utf-8?q?hell?=
=?utf-8?q?o?=
should be presented as:
Subject: hello
And
Subject: =?utf-8?q?hell?= =?utf-8?q?o?=
should be displayed in the same way; there is no interaction between the
unfolding operation and the decoding of encoded words.
on the other hand,
Subject: =?utf-8?q?hell?=
o
should be folded into
Subject: hell o
my suggestion is to add the reference, perhaps like so
Long header lines are unfolded (as described in [IMAIL] 2.2.3
and [MIME] part 3 6.2) prior to interpretation of the data.
IMO it would be better to say something along the lines of
Header lines are unfolded as described in [IMAIL] section 2.2.3.
Interpretation of header data should be done according to [MIME3]
section 6.2.
This makes the required sequence of operations clear. Note that I also removed
the term "long" - in practice it isn't only long lines that are folded.
Ned