On 4/2/2015 7:48 AM, John Levine wrote:
> It occurs to me why this is still DKIM -- the external interface is
> the same. You call a DKIM verifier by, roughly, giving it a mail
> message, and it tells you what the d= was on the valid signatures.
> That doesn't change. Anything that uses DKIM v1, whether it's DMARC
> or a Spamassassin plugin, uses v2 the same way.
>
> On the signing side, the signer has the new option of adding a conditional
> signature, but all of the old options still work.
Protocols are defined by bits over the wire, not APIs.
The most striking example of this point that I had to deal with was
NetBIOS.
IBM published the API but not the protocol. A few different LAN
companies each created their own proprietary protocols that conformed to
the API, but which were wildly different from IBM's and each other's.
The fact that the new ones all ran over TCP didn't matter:
They Did Not Interoperate.
Eventually there was market pressure to interoperate and we were forced
to collaborate on the development of RFC 1001/1002.(*)
FWIW this confusion about the nature of 'upgrades' is a relatively
consistent pattern over the years. It plagued some of the recent
internationalized email work, which bogged down in trying to define both
a new mode and the shared operation with new and old modes. And it
plagued IPv4/IPv6, although in the reverse direction: v6 could have been
an almost-compatible upgrade, which would have made gatewaying trivial
and deployment probably 15 years earlier...
d/
* It was also my introduction to the difference between skills in
implementing a protocol specification, versus skills in designing one.
Being quite good in the former was no prediction of competence in the
latter...
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
dmarc mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmarc
