&TL;DR Good start; absent a bit more formality, it is hard to understand how to implement the work.

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

Attachment: OpenPGP_0x87B66B46D9D27A33.asc
Description: OpenPGP public key

Attachment: 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

Reply via email to