-----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-----
_______________________________________________
Ietf-dkim mailing list -- ietf-dkim@ietf.org
To unsubscribe send an email to ietf-dkim-le...@ietf.org
