All, I'd really like to get a final consensus of the changes for the next draft. So far I have the minor changes, including the updates needed to the example.
Is it fair to say we have consensus on the one report per failure? What is the final verdict on the DKIM-Canonicalized-Body? How should it be phrased in the doc? Thanks H > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of > Alessandro Vesely > Sent: Friday, October 21, 2011 4:40 AM > To: [email protected] > Subject: Re: [marf] New Version Notification - draft-ietf-marf-authfailure- > report-03.txt > > On 20/Oct/11 20:16, Murray S. Kucherawy wrote: > >> From: ietf.org On Behalf Of Alessandro Vesely > >> > >> All right, I think the amount of guesswork is minimal (e.g. what if > >> l=1?) and the recipient should be prepared to "massage" the datum > >> anyway, according to what format was saved on signing, for comparison. > > > > So you're saying DKIM-Canonicalized-Body should always be the complete > > body, and receivers of these reports should apply the truncation based > > on the "l=" found in the third MIME part? That seems a little > > convoluted to me. > > However convoluted it may seem, that's the formal definition that DKIM > gives of the body canonicalization algorithms. Of course, both signers and > verifiers know it is useless to canonicalize parts of the body that don't > contribute to the hash. By skipping useless parts, they obtain the same > result "as if" they had carried out a full body canonicalization and then > truncation. > > Report generators are in a different position, because what used to be an > intermediate result is now visible. Pedantic programmers may conclude that > they need to send the whole body by reasoning as I did above (uh... does > that mean I'm pedantic?) You yourself adapted to write CRLF for an empty > body, l=0 notwithstanding. > > What I'm saying is that if we want it to be clear and indisputable that DKIM- > Canonicalized-Body may/must be limited to the amount of text that > contributes to the hash, we have to say so. > > > This format is completely useful even if none of the reporting > > extensions drafts ever get published. The opposite is not true. > > Admitted. That may be an advantage, even though it comes at the expenses > of method-orientation. > _______________________________________________ > marf mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/marf _______________________________________________ marf mailing list [email protected] https://www.ietf.org/mailman/listinfo/marf
