> 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.
Personally, I would say it should be "foo:=20bar". That's the only
truly consistent answer.
> 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.
Great, sounds like the two of us, at least, are on the same page.
> 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
Sorry, I don't understand. I'm suggesting that if a wrapped header
field is passed to DKIM, it should encode that in z= as =0a=0d ---
that's from the above. My point here is that the current spec says
something like "Q-P as defined in 2045", but in fact we are using
something slightly different. 2045 does not allow arbitrary
non-significant white-space, requires that an existing CRLF sequence
be encoded that way (not as =0a=0d), and requires "=CRLF" to mean a
soft break. This essentially violates all three of these.
So in some sense my question is: shall we continue to reference 2045
and add in all the exceptions, or come up with yet-another encoding
that might strongly resemble 2045 but which will not be identical?
The result is the same, it's just the mechanics of the spec I'm
questioning.
> 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=?
As in, replace "|" with "=20"? That doesn't seem like a good idea to
me because of the line wrapping problem. I think it would be good to
be able to encode a header such as:
x: a
b
y: c d
with
... z=x:=20a=0a=0d=09b|y: =20c=20
=20d;
Note that the actual white space in the encoding is /not/ part of the
original input, which is all encoded. If I'm understanding your
suggestion, you would have to encode that as
... z=x: a
b=20y: c d
or maybe
... z=x:a=0a=0d=09b=20y:c d
which I'm reasonably certain is not what you mean --- so I think I'm
misunderstanding.
eric
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html