On Wed, 04 Feb 2009 18:40:14 -0000, Eliot Lear <lear(_at_)cisco(_dot_)com>
wrote:
No, SHOULD NOT is too strong. Normally, that would indeed be the case,
but
in specific cases the Assessor (not the Verifier) might have
information,
obtained by some out-of-band means, what that particular i= meant, and
be
able to act accordingly. Otherwise (and maybe always), assuming the d=
matched satisfactorily, the i= should just be passed on to the end user
who might make some sense out of it (e.g. Aunt Tillie vs Uncle George).
First, I stuck to terminology that was in RFC 4871 intentionally, with
an eye toward keeping the errata simple.
Yes, but we are currently discussing Dave's errata, which carefully
distinguishes between the Verifier, which does the purely machanical
checking of the signature for validity, and the Assessor which decides
what action to take on the result.
Second, there is a predicate prior to the SHOULD NOT statement which is
important. However, it has been lost by more than one person indicating
lack of clarity. Let's try this again:
Yes, I take the point about your predicate. My main target was Dave's
remark (Mon 02 Feb 2009 19:42:44 GMT)
Since the new consensus appears to be that i= has semantics that are
entirely undefined, it does not seem possible that the wg would advise
showing it to an end user.
But I now see that such wording does not appear in his actual latest
draft, and the current thread seems happy that the end user should indeed
be given the opportunity to differentiate between Aunt Tillie and Uncle
George in cases where the Assessor had insufficient information to utilize
that inormation itself.
--
Charles H. Lindsey ---------At Home, doing my own thing------------------------
Tel: +44 161 436 6131
Web: http://www.cs.man.ac.uk/~chl
Email: chl(_at_)clerew(_dot_)man(_dot_)ac(_dot_)uk Snail: 5 Clerewood Ave, CHEADLE, SK8 3JU, U.K.
PGP: 2C15F1A9 Fingerprint: 73 6D C2 51 93 A0 01 E7 65 E8 64 7E 14 A4 AB A5
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html