Michael Thomas wrote:
Stephen Farrell wrote:
Michael Thomas wrote:
Stephen Farrell wrote:
Even if it doesn't hit anywhere else, presumably the EAI work will
have to be taken into account for the z= field, with potential
changes being required to the current ABNF?
I'm not sure about the ABNF, but why would it otherwise affect us?
The z= is only a qp encoded blind copy of the bytes present. We don't
define any semantics.
Answer is: I don't know. That's why I asked the question. Hard to
believe that we won't get hit by EAI, but great if so. I'm thinking
about the unfortunate PEM/MIME situation and just want us to keep it
in mind as EAI progresses.
I thought that our ABNF had a restriction to certain characters only,
but didn't read it carefully enough to be sure if that applies inside
the z= field. (z= being at the end of the list, I was tired of reading
when I got there:-)
It does, but the value of the z= is QP encoded so that there aren't
conflicts with the DKIM/2822 ABNF. Do you have an example of where,
say, QP or base64 encoded data could still bite you?
I don't. And don't understand the details enough to say. But if
no-one else does either then we'll be able to close the issue and
move on.
S.
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html