Eric Allman wrote:
> --On June 10, 2006 2:53:06 PM -0700 Michael Thomas <mike(_at_)mtcc(_dot_)com>
wrote:
>
>> Arvel Hathcock wrote:
>>
>>> How are multi-line header field values to be handled with z=? Do
>>> we encode the fold (by adding =0D=0A for example) or do we unfold
>>> the header field value first and then add that result to z=? Is
>>> preserving the fold important at all?
>>>
>> Another interesting question looking at your headers is that you
>> include the leading space of the header while I don't (due to that
>> artifact of milters). I'd say that you're probably right given my
>> previous message.
>>
>> Eric, what do you think?
>
>
> I had intended that the format be unambiguous, so that all white
space (which should be SWSP) is encoded. Given the current ABNF, this
means that the only folding permitted would be before a "|" or after a
":", which may not be what we want.
Definitely not what we want. The tags and values *must* be able to be
folded as necessary.
> I think it's a bad idea to allow white space (including CRLF) to mean
literal white space, since one of the things we are probably trying to
preserve in z= is the original white space and folding of the original
header fields.
Right. Especially for simple. But what about:
"foo: bar" should that be "foo:bar" or foo:=20bar"? This is sort of
related to the
milter simple bug the separator white space. Mine currently does not
insert this
at like it similarly assumes that the separator in simple is =20. It
would be nice to
squash these once and forever.
> So it seems that requiring all SWSP to be encoded and then allowing
perhaps arbitrary addition of real SWSP simply to keep down line lengths
may be the right thing to do.
That's what I do.
> Much of this violates RFC 2045 section 6.7, notably points (4) and
(5). Point (5) (soft line breaks) is especially problematic since they
are indicated by "=CRLF" in 2045, but header folding requires at least
one white space after the CRLF.
but what about =0a=0d? That's all I do. But I thought that the curret
draft requires that swsp
be encoded? Then any swsp is clearly 822 syntax
> This clearly needs to be fixed up --- it is definitely ambiguous now.
My suggestion is to require that all SWSP in the original header be
encoded, and all physical SWSP in the z= tag (specifically, qp-hdr-value
in the ABNF) be ignored.
Can I make an ever humble suggestion that we also define simple to
define the
simple separator character ws to be =20 and that we just elide the
separator character for z=?
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html