On Thu, Apr 2, 2015 at 9:18 AM, Dave Crocker <d...@dcrocker.net> wrote:
> > The main difference I see is that if we call v2 something else, we now > > have a tedious administrative exercise of finding every place something > > refers to DKIM and change it to "DKIM or DKIM-plus." This does not > > strike me as a good use of anyone's time. > > That task you characterize as tedious is, in fact, the discipline of > making sure the documentation is careful to distinguish between the two > different (ie, non-interoperable) protocols. > > Efforts to do that with a single specification wind up confusing things > and confusing readers and implementers. I'm using API terminology here but I think the comment generalizes to the protocol: If the input is "the message" and the output is "a set of zero or more SDIDs representing domains whose signatures validated", then I don't think it matters if we go the "v=2" route or the "new header field name" route, because the multiplexing happens on the inside of the processing machine thus described. However, and perhaps unfortunately, RFC5672 changed it so that the output of DKIM is a single SDID. That means either (a) RFC5672 got it wrong, because this doesn't allow for the whole message to be the input and multiple domain names (for passing signatures) to be the output, or (b) the above definition is wrong, because it means a single DKIM signature _plus_ the whole message is the input, and the algorithm picks apart the message as needed to complete the verification and thus produce the single SDID (or an error). OpenDKIM certainly implements the first definition I've used above at its API level, though I could argue that it satisfies either of the two definitions and just happens to do the latter one in a parallel way. -MSK
_______________________________________________ dmarc mailing list dmarc@ietf.org https://www.ietf.org/mailman/listinfo/dmarc
