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. But there are strong arguments suggesting this should be its own thing entirely, and in that case it remains to be seen how much code I'll be able to re-use when implementing EKIM[*]. I'm curious about your use of "stigma" though. What have you observed? -MSK [*] I'm going to keep trying different names for the new thing until something sticks, or we commit to it not being a new thing.
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
