>In the latter case, it's really an entirely new protocol, which should >be identified by the next-lower protocol, rather than by using the >version field as an in-bred demultiplexing field.
I suppose, but if the two procols are 99% the same, and the new one is upward compatible with the old one, and anything that understands the new one also has to understand the old one, and the goal is to have everything puts semantics on the old one put the same semantics on the new one, I'm having trouble seeing why one of these is vastly preferable to the other: DKIM-Signature: v=2; d=example.com; ... DaveKIM-Signature: v=1; d=example.com; ... In this particular case, the incompatibility is a new kind of "must handle" tag suggested by Ned Freed with the new rule that if a verifier doesn't understand it, the verification fails. The first of them would be must-re-sign, which means that the message has to be re-signed by another domain, e.g.: DKIM-Signature: v=2; d=yahoo.com; @mr=ietf.org; ... which would say this signature is only good if there is also a DKIM signature with d=ietf.org. You could chain these things which might deal with the educational forwarding issue that Elizabeth Z. described. Once you have the syntax for must handle tags (I used @ here) then we can add more of them as needed without another version bump. R's, John _______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
