[Ietf-dkim] Calls for adioption of documents

[Richard Clayton <[e-mail]>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


#1 draft-gondwana-dkim2-motivation

    The WG is chartered to determine what issues DKIM2 is going to
    address, and this is a good starting point for that discussion and
    so in my view it should be adopted for that purpose.

    I think it's unlikely to be desirable to attempt to turn it into an
    RFC ... but some of its text could well make it into an
    informational document that taught people how to best deploy DKIM2
    to best address these issues.

#2 draft-gondwana-dkim2-modification-alegbra

    It is pretty clear to me that we need to be able to undo changes in
    order to check that the original signature on a message was valid
    (ARC, which suggests we might be able to trust someone else to do
    that has not got any traction and I don't think that will change).
    As such this is an excellent starting point for the WG to consider
    the trade-offs between expressiveness, simplicity and practicality.

    I would have preferred a design that was more focused on what
    mailing lists felt they needed to do when altering messages, but I
    have been persuaded that there would be very significant complexity
    in tying down apparently simple descriptions such as "I just added a
    footer" when emails are complex MIME structures with non-ASCII
    encodings. Hence I think this document is where we should work from.

#3 draft-gondwana-dkim2-header

    The case for adopting this document at this point in time is less
    clear-cut, in my view.

    It is the rump of the document Bron, Wei and I originally wrote to
    explain our vision of DKIM2. The "issues to be addressed" were
    carved out into #1 above and this document is what remains. As such
    it has significant value to address objections along the lines of
    "well that might be a problem but there's no way to solve it simply"
    but otherwise it is not something that it would be possible to
    implement against and making it into such a document is a lot of
    changes.

    I am a fair way through producing a document based directly on
    RFC6376 -- which has the advantage of keeping text identical when it
    is not proposed to do anything but work-alike with DKIM1 -- but it
    is of necessity very long (because I am trying to keep all the ABNF,
    the detailed descriptions of algorithms etc) and hence it may be
    hard to see the wood for the trees, and so it might be a while
    before WG participants understood what was changed and what was not
    -- whereas the draft proposed for adoption is relatively short and
    it avoids pretty much all of the detail.

    I don't think that -- given the workplan -- for the WG there is a
    pressing need to adopt #3 at the moment, and it might be a
    distraction to do so. If we did adopt it then I would expect to
    shortly be filing a ticket to replace the whole thing with new text
    ... or some procedural equivalent.

As people are doubtless aware I am an author of #1 and #3 (and I am the
"Richard" you can find in the Bangkok minutes).

- -- 
richard                                              Richard Clayton

They that can give up essential liberty to obtain a little temporary
safety deserve neither liberty nor safety.         Benjamin Franklin

-----BEGIN PGP SIGNATURE-----
Version: PGPsdk version 1.7.1

iQA/AwUBZ/WyT2HfC/FfW545EQLwzwCfTVlCzt5Uml7F7K5ipnQi2fQihwsAoKFd
9Hq/y7CY/D+plFXTYjukjjb/
=fLpb
-----END PGP SIGNATURE-----