-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 At the end of January Dave Crocker posted a review of the then current "-01" version of draft-gondwana-dkim2-motivation. This document has now been split into an "-02" and draft-gondwana-dkim2-headers (-01).
Rather belatedly this is a response to that review, albeit spread over 14 (sorry) emails... ">>" is a quote from our document, ">" a quote from Dave Crocker ... lines that do not start with a ">" are me speaking. - -=-=-=-=-=-=-=-=-=-=-=-=- >> 2. Design Goals >> >> 1. It is intended that legacy mail systems constructed in the last >> century will be able to interoperate with this new specification. >> However, more recently developed systems will, after a period of >> parallel running, need to be upgraded in order to continue to be >> able to authenticate email. > >What are the technical differences between the two? Why make the distinction? > >Anyhow, so yes, this is a complete infrastructure replacement. > >(btw, the Internet's fairly consistent history with "a period of parallel >running" is that the period is forever, or at least some decades. cf, >RFC2822's >attempt to 'obsolete' constructs. > >As such, any description of this process as 'transition' is unrealistic and >even >misleading. > >> 2. We favor simplicity over obscure functionality. > >False, straw dichotomy. > >Also not all that helpful in design guidance discussions, in spite of seeming >like it would be. Rather, it adds an awkward and arguably arrogant tone to the >draft. > >On the other hand, what might be intended is something like: > > 2. Favor simple, minimal, essential design features, to facilitate > adoption and use. > >(and I note that draft charter 5 has language along these lines. > > > >> 3. We aim to keep the number of cryptographic operations required >> the same or less, for all the most common types of email flow. > >Same or less than what? Presumably DKIM? > > > >> 4. We aim to make all parts of the specification mandatory to >> implement because experience shows that interworking is adversely >> affected by providing optional functionality. > >This misses the difference between essential core, versus useful enhancement. > >Consider email operation or enhancement with no SMTP options. This section no longer exists in -02 and where some of the material has been kept it has been substantially rewritten viz: we did read this review at the time and took note -- and of course others commented to us as well on and off list. However, we didn't reply on the list, a lacuna which I am now addressing. - -- richard Richard Clayton Those who would give up essential Liberty, to purchase a little temporary Safety, deserve neither Liberty nor Safety. Benjamin Franklin 11 Nov 1755 -----BEGIN PGP SIGNATURE----- Version: PGPsdk version 1.7.1 iQA/AwUBZ/l0XmHfC/FfW545EQKFAgCgpwOvdXxwKyOBIiPMzWDZ/ocCJ38AnA7r aK2rmSuwK6R25VyRGzCU+/Fk =wdv2 -----END PGP SIGNATURE----- _______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org
