> >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; ...
Without getting into the desirability/utility of any sort of v2, I'll note that
the latter of these has one small advantage: It avoids any issues with broken
DKIM handlers that fail to correctly interpret the v= field.
Having said that, I think the version bump approach is a pretty significant
aesthetic win, especially if the change is, as noted below, to implement the
"must handle" tag.
And aesthetics in protocols do matter to some extent.
Ned
> 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
_______________________________________________
dmarc mailing list
dmarc@ietf.org
https://www.ietf.org/mailman/listinfo/dmarc
