Dave says...
In terms of working group process, one line of criticism demands re-opening
(and, apparently, reversing) the work of the Update (RFC 5672). I haven't
seen
any working group consensus to do this nor any industry feedback indicating
this
is necessary. Consequently, attempts to pursue the content of that work is
entirely out of scope for the current working group effort.
I'll point out that Dave is offering his *opinion* about whether this
is in or out of scope.
I'll provide the chair's judgment on that, as the one who has the task
of determining scope: it's out of scope. We had this discussion back
when we did 5672, and got rough consensus on it. Not unanimity, but
rough consensus. We're not going over that again. 4871bis is, and
should be a merging of 4871 and 5672.
Barry, as chair
Doug says...
This can *only* be achieved by some mandatory test within the Verifier.
Not at all; that's exactly Dave's point in discussing the difference
between the protocol and the software system that wraps around it.
The Verifier is a component that verifies the signature, and that's
all we're defining normatively here. Other parts of the system will
evaluate things whether the verified signature can be relied upon, and
what it can be relied upon for; whether the domain that signed it is
trustworthy; whether a failed signature can nonetheless provide useful
information; and so on.
It's reasonable to give non-normative advice, perhaps strong advice,
about what other system components might do in that regard. Most of
that advice should be in the other, informational documents, and some
might even reasonably be here (and some of it is). But it can't be
mandatory. I'll point out what Paul Hoffman had said many times in
earlier discussions: you can't control what the receiver [meaning the
overall system on the verification side] will do... you can only give
it the information.
Barry, as participant
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html