Finally answering this thread after being consumed by $DAYJOB for a while now, and with apologies for same:
On Wed, Sep 3, 2025 at 2:33 PM Bron Gondwana <brong= [email protected]> wrote: > On Thu, Sep 4, 2025, at 04:59, Dave Crocker wrote: > > 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. > > > OK, we're definitely in terminology confusion here. Integrated means "you > have to implement all these things or you are not in compliance". You are > arguing for the opposite, which I characterise as "we should design > something which you could implement part of and still get benefit". > > My meaning of "omnibus" (and Murrary, please chime in and confirm whether > that's what you meant) is "you have to implement all the bits to say you > support DKIM2". > The dictionary appears to define "omnibus" as "comprising several items". My use of "omnibus" was meant to address the discussion we heard at IETF 123. The room seemed to be debating whether "all the bits" should be done at once (i.e., in a single, omnibus document) or could be accomplished piecemeal (i.e., via individual, incremental documents). The discussion that I recall suggested that for a few reasons an omnibus approach was preferred by the WG, namely: * as Bron said, we want to declare that DKIM2 is the full collection of all of those bits, nothing less * for any ordering of those bits, at some point you cross a line where they are no longer strictly incremental over DKIM * it is unlikely that anyone would implement some but not all of these bits A possible compromise at least on the first bullet might be to publish all the bits individually and then issue DKIM2 as an applicability statement asserting that you have to do all of them to comply, but I don't know off the top of my head what that would look like given the second bullet. > It IS interoperable at the operator level. You can keep the same DNS > entries, replace the software, start doing both DKIM and DKIM2 without > changing your DNS entries. That's not nothing. For the vast bulk of > domain owners, this is the thing that makes their life easier. So > operationally, it's interoperable. > > And... I still believe that at the technical level it can not be done to > be backwards compatbile at the "reuse same-named header / be > cross-interoperable". > Dave mentioned the use of "backward compatibility" and "transition" and asserted that these are contradictory. I disagree, and I suggest that consensus in the room did as well. He said backward compatibility: "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 But this new thing is being constructed in a way that does not impact DKIM operation at all (as far as I can tell). In that sense, it interoperates with DKIM just fine, or at least does not disrupt DKIM's operation; it's backward compatible. They only thing they have in common is some syntax characteristics (the header field and the DNS records). And then, once the design of the new thing is stable and giving the desired signal, DKIM would presumably be wound down, at least at those operators for which the new things's signal is a superset of what DKIM provides. At that point those operators would stop using DKIM. That to me qualifies as a "transition"; at time T0 there is only DKIM, and at the end there is only the new thing, yet no disruption of DKIM itself occurred. That doesn't seem like a contradiction. Process-wise, I think we still have consensus to proceed with a Call For Adoption on the "header" document. Does anyone disagree? -MSK
_______________________________________________ Ietf-dkim mailing list -- [email protected] To unsubscribe send an email to [email protected]
