I really like the goals laid out in this work. The original DKIM couldn't accomplish what was being proposed, in particular reversibility. I am excited about your direction, and I'm convinced by your *intent*.
I have a few comments about the drafts:They are *extremely* drafty and require a bit more formality to the work, and that makes them difficult to read.
I have four principal recommendations: * Use ABNF for all parameters. * Use active tense RFC 8991 language. * Have a complete narrative description for all parameters. * Consider providing pseudo-code for each anticipated operation. * Use complete examples that build on one another. Details and examples follow:There are some inconsistencies. i= is defined as "DKIM2 matching header number" in the delta draft and "Sequence Number (from 1 to N)" in the -header draft. Maybe they mean different things? It's hard to say because there is no crisp semantic definition in either document, and yet I perceive this as a core aspect (maybe I'm wrong?). I'm hesitant to try to give a clear proposal here because I'm likely to get it wrong. Having a more detailed narrative description of each parameter will help.
The formality should include use of appropriate RFC 8991 language and active tense. So for example, instead of:
DKIM2 allows for extension headers which are always added to the signature, but ONLY where they have an i= with a value equal to or lower than the matching DKIM2 header. This allows for extensions to add something at each DKIM2 hop; with it automatically added to the signed header set.
Maybe:
MTAs implementing DKIM2 MAY sign extension headers, but they MUST only do so when the i= value of that header is less than or equal to the matching DKIM2 header.
I'm just guessing because I don't know what "matching DKIM2 header" means!With -algebra, I really appreciate the attempt at examples, but quite honestly the language is not precise. For example:
DKIM2-Delta-Body: i=2; c=0-19452; c=20312-150 Example - appended to some base64 content; so we need to add back the last few characters (and the mime trailer)
Even with the intent in the example, I don't understand how you got there. To begin with, the grammar is not correct, so I am not sure what did the appending. Was it MTA 2? If so, how do you know it was base64 content, and how do you know it was appended? I don't see a clear formula.
I presume that there is no introduction in -dkim2-header YET, but that it will come in due course. Much of what is in the -motivation document could be reduced to a nice intro, and cover document organization.
I suggest a big fat editorial scrub with some ignoramus such as myself asking ignorant questions might help. The phrase that would come out of my mouth on a fairly regular basis would be "what do you mean by"? Alternatively, you could try to see if Co-Pilot produced reasonable code from your intent ;-)
Regards, Eliot
OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key
OpenPGP_signature.asc
Description: OpenPGP digital signature
_______________________________________________ Ietf-dkim mailing list -- ietf-dkim@ietf.org To unsubscribe send an email to ietf-dkim-le...@ietf.org