On 1/5/25 6:45 PM, Murray S. Kucherawy wrote:
On Sun, Jan 5, 2025 at 4:51 PM Michael Thomas <[email protected]> wrote:
[...]
To me, the charter should say something like "Solutions that do not
involve breaking changes to DKIM (rfc xxx) should be preferred
unless it
is absolutely necessary. Where a breaking change is something that a
naive receiver verifier would not be able to verify even if
doesn't take
advantage of any new features. This would vastly simplify
transition and
leave it to receivers judgement whether making the upgrade is
worth it.
My understanding (which could be wrong) is that the general idea is to
deploy a new protocol that is an evolution of the existing one. DKIM
as it stands today would be unmodified, but would theoretically become
obsolescent in the face of the new thing once it reaches critical mass.
If I've got that right, then it might indeed be good to make it clear
in the charter that this is the express intent, and not extensions or
enhancements of the architecture in situ.
My point is that I think it can likely be retrofitted to DKIM proper. I
mean, we did think about futures and not getting everything right
upfront. This was one of my criticisms about ARC.
If we could upgrade parts we'd like to upgrade but keep it within the
DKIM umbrella, it would be just an upgrade not a new deployment. That is
generally easier than asking the community to deploy something new.
There is something of an advantage of writing one DKIM-Signature instead
of two or more since signing is the expensive operation. Having some new
tags and/or new headers to sign is pretty trivial in comparison to
rolling out something "new".
Mike
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
