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?
d/
--
Dave Crocker
Brandenburg InternetWorking
bbiw.net
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html