I'm uneasy with an increase in version that isn't done in a complete replacement for RFC6376.
The problem may be that we don't agree about what DKIM versions mean. Here's what I would like them to mean:
a) The lexical syntax of DKIM signatures will never change, and a v=1 parser will aways be able to find and parse all of the tags in a signature. (If you need to change the syntax, invent a new header name.)
b) We will never change the meaning of defined tag. (If you want a tag that means something different, define a new one.)
c) Whenever we add new tags that require that the verifier understand them to get the right answer, we increment the version number.
d) Versions are cumulative. Every signature that is a valid version N signature is still a valid version N+1 signature, give or take the change in the b= hash due to the version bump.
Key records don't need version numbers, since a key should only be used by signatures at a version high enough to handle whatever is in the key.
This sort of versioning seems to work fine for file systems and other constructs where there's no feedback from the reader back to the writer. Either the reader can deal with it, or not. But a version bump is not a big deal, and doesn't require reissuing the whole spec.
I can think of a variety of ways to get this effect by hacks that stay at v=1, e.g.
R's, John _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
