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
