Eric Allman wrote:
> 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.
I can live with that.
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.
Given how simple our qp-like encoding is, I think you might be right
to just say in an informational way that it's similar to 2045, but really
define the encoding ourselves.
> 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:
No, no. I meant that we simply define the white space separator as space,
both for this and simple regardless of whether it was space, tab, etc. Then
we wouldn't have to do any unnatural acts with milters :)
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html