On 4/1/2015 8:22 PM, John Levine wrote: >> 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
'Upward compatible' was carefully distinguished from 'different protocol'. Upward compatible says that the new one is a superset of the old one. That is, all the old stuff is the same, but there's some /additional/ stuff. The pattern is that the new stuff self-distinguishes. In which case the version field provides no useful information. Worse, the usual model of enhancement is a series of increments, where the increments often need to be used in different combinations. Each bit of increment needs to self-identify so that the receiver knows which enhancements are being used. Version fields don't support combinatorials like that. > 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; ... Nice example of useless version info. The fieldname provides all the distinguishing information that's needed, for the differential syntax and/or semantics. The reason it is better to use fieldname is because the engine that decides how to dispatch to code that understand the contents of a field only needs to look at the fieldname, rather than the fieldname and the version field. > 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 Right. So an older implementation sending to a newer one is trying to talk a different semantic than the newer one requires. Hence, they do not interoperate. Hence the demultiplexing between them should be in the lower-layer dispatcher. In the case of a DKIM-bis-ish change, that means a different header field name. It really is a different protocol. > 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. What you have described is an overlay protocol. It logically sits above DKIM, since in additional to doing it's own thing, it "uses" DKIM. The fact that it looks quite a bit like DKIM is a distraction. It has an essentially different semantic. Remember that chimpanzees have almost all the same genes as humans. But they aren't human. Or perhaps we aren't chimpanzees. (Well, most of us aren't.) > 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. Changing the must-implement set changes the basic protocol into a new protocol. Adding optional ones doesn't. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net _______________________________________________ dmarc mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmarc
