On 3/31/25 10:53 AM, Murray S. Kucherawy wrote:
On Mon, Mar 31, 2025 at 10:45 AM Jim Fenton <fen...@bluepopcorn.net>
wrote:
> I seem to recall previous discussions have suggested that the
"v" tag
> shouldn't have been included in the first place; if things are
so different
> that you need to change the version, you may as well change the
name of the
> header field altogether.
That matches my recollection as well. We never defined the
semantics of a change in the v= value.
I get the sense that some feel there’s a stigma associated with
the name DKIM, so the new thing ought to be given a different
name. I have thought much the opposite, that calling the new thing
“new and improved DKIM” would be accepted better because people
have some idea what DKIM is. But that’s basically a marketing
consideration, and I’m terrible at that so don’t listen to me.
Of course, this all assumes that the new thing can’t be made
backwards compatible with DKIM.
As an implementer, there are some seriously attractive benefits from
making this backward-compatible with STD 76 DKIM. One of those is
that the amount of code reuse goes way up, meaning it will be way less
effort to get to prototype. In my own implementations, supporting
differential logic based on the value of a changed "v=" tag would be
very easy. From that perspective, I would really like this to be
backward compatible.
That's been my point all along too. It's also the creature that is well
known and understood both for development as well as deployment. The
latter is no small thing -- it's always a crap shoot whether something
new will be deployed versus something deployed getting a software update.
Mike
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
