[ietf-dkim] Clarification on z=

[Eric Allman]

> > 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