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? >> * 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". (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) >> "allows for interoperability >> <https://en.wikipedia.org/wiki/Interoperability> with an older legacy system >> <https://en.wikipedia.org/wiki/Legacy_system>, or with input >> <https://en.wikipedia.org/wiki/Input/output> designed for such a system." >> >> https://en.wikipedia.org/wiki/Backward_compatibility > The technical details of DKIM2, so far, and all of the substantive > discussions, are for a parallel and non-interoperable service. > Agreed. > > >> * This will be a new protocol with a new header field name, rather than a >> new version of DKIM itself (i.e., a “v=2” tag). > Exactly. NOT backward compatible. > Agreed. It's not backwards compatible, it's parallel-deployment compatible. Cheers, Bron. -- Bron Gondwana, CEO, Fastmail Pty Ltd / Fastmail US LLC [email protected]
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
