On 8/31/2025 2:22 AM, Bron Gondwana wrote:
On Sat, Aug 30, 2025, at 03:20, Dave Crocker wrote:
On 8/29/2025 10:03 AM, Murray S. Kucherawy wrote:
* Adopt Bron’s document, and prefer a more omnibus approach,
breaking out things when it makes sense to do so.
Apologies. In spite of the added clause, I do not know what
'omnibus' means in this context, given the definition of the word.
My recollection was "design an integrated specification/protocol which
addresses multiple issues rather than taking a piecemeal approach of
trying to solve each problem individually without a wholistic
overview". That sounds like buzzword bingo even to me as I re-read it,
but I think it's accurate.
Does that help? Others - does that match your recollection?
I think it underscores the misunderstanding. The view that being
'modular' precludes also having an overview is simply nothing like what
I have ever espoused. Nor anything I have written, said or impled, or
meant.
Note, for example, that your own team's line of effort has started
breaking components out into separate documents (modules.)
So, fully-integrated or 'omnibus' does not describe what your team's
efforts are actually producing. So, to invoke a cliche punchline, we
are merely haggling about price.
At the base of my own effort are the views that:
* Much of what is desired has little or nothing to do with the
existing DKIM and therefore has no business being in a document that
purports to be about DKIM, and
* What does pertain to DKIM does not require changing the base DKIM
spec but can, instead, be done as one or more value-added
specifications.
The reaction to the spec I offered was that, somehow, it was meant as
being instead of the entire range of your teams spec. It wasn't and was
never cast in those terms.
Rather, it was offered as an example of carving out some of what your
team is attempting, but in a way that is compatible with existing DKIM
and therefore can avoid the (very long) parallel 'transition'.
Your team's effort has dismissed the utility of preserving the installed
base. In spite of extensive Internet experience with the challenges
that produces and the significant track record of failures. And in
spite of noting that those failed efforts had advocates very bit as
confident as your team is...
Also note that your team is producing something that is not
'interoperable' with existing DKIM. Reusing components is not
'interoperability'. Interoperability means that one instance can
directly interact with the other. That ain't what you folks are doing.
It is, however, what I believe /can/ be done.
* There will be backward compatibility with DKIM (referred to in the
room as a “transition”); there will be no flag day.
Except that 'backward compatibility' and 'transition' are orthogonal
constructs.
I don't fully agree with Murray's characterization here.
My understanding was more "there won't be a pre-planned and centrally
coordinated flag-day suggested by the IETF, but individual sites will
likely prefer DKIM2-complete messages; and once they feel that a
sufficiently small percentage of the traffic their users want is not
DKIM2-complete, they might mandate it".
And indeed, that is the only form of 'transition' that has been possible
on the Internet pretty much forever. (Even the January 2983 flag day
didn't achieve it. Not really. My understanding is that it was 6 months
before things stabilized.)
But my intended point about being orthogonal is that backward
compatibility and transition mean largely unrelated things. The first
says that the old features and implementations continue to work .
Forever. (And please note that 'forever' is an essential requirement,
when talking about Internet transitions, which are typically measured in
decades.)
The second is about being able to move everyone to using the new features.
So, for example, as the many, independent sites choose to adopt the new
stuff, they can still interwork with the old implementations. That's
backward compatibility. The choosing is transition.
(rough definition: DKIM2-complete; there is a sequence of DKIM2 header
fields with no gaps per the "destination domain of |rt=| on hop
|n=i| matches signing domain of hop |n=i+1|" rule and the
|n=MAX| header field has an |rt=| on the receiving system)
So, that is a re-do of ARC, not DKIM.
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
bluesky: @dcrocker.bsky.social
mast: @[email protected]
_______________________________________________
Ietf-dkim mailing list -- [email protected]
To unsubscribe send an email to [email protected]
