Dave Crocker wrote:
Jim Fenton wrote:
Most of the sections under 3.2, "Operational Goals", are really goals
in the sense of "I want a mechanism that...". So "I want a mechanism
that permits incremental adoption for incremental benefit" makes
complete sense. As does "I want a mechanism that minimizes the
amount of required infrastructure."
But section 3.2.1, "Treat verification failure the same as no
signature present" doesn't strike me as a goal, but rather a
consequence of the way that the mechanism works. I would probably
rather have something that can treat verification failure more
harshly, but it doesn't work that way. This really ought to be
merged with section 5.4, "Unverified or unsigned mail" instead.
Let's try to tackle your last point, first. Section 5.4 is a
description of the architecture. It's certainly a reasonable place to
observe that failures are treated the same as no signature, as indeed
5.4 does. However that is different from describing higher-level
goal-like issues, which is what section 3 is intended to be. By
'higher-level' I mean the stuff of significant constructs that
motivate the work.
Now to your primary point: DKIM's treating failures the same as
no-signature is an unusual characteristic that captures folk's
interest. From a pedagogical point of view, it warrants highlighting
as an distinctive construct.
Whether it deserves its own, explicit listing or whether it should be
folded into one of the other entries (such as the current 3.2.2) is
another matter. It seems to get enough attention to warrant being
cited on its own, but I do see your point that it feels different from
the other 'operational' goals. I am not sure how to reconcile that.
Do you see the current Overview document form as doing any particular
damage to one's understanding of DKIM?
It's just that the other goals sections do a good job of stating the
value proposition of DKIM, and this is a different sort of thing that I
think waters down what is otherwise a very strong section of the
document. If you can't come up with another place to cite it on its
own, I'd suggest listing it as the last rather than the first
Operational Goal.
-Jim
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html