On Sat, 14 Jul 2007 21:01:34 +0100, Paul Hoffman
<paul(_dot_)hoffman(_at_)domain-assurance(_dot_)org> wrote:
Many thanks to Dave for bringing this up.
At 2:55 PM -0400 7/14/07, Dave Crocker wrote:
The overview document states that it is seeking Informational RFC
status. Further, it does not include the usual citation and statement
that normative vocabulary is used to assert normative requirements.
Nonetheless, the document has quite a number of apparently normative
statements -- including some in uppercase -- such as:
. . .
This seems anomalous and raises a line of questions:
If the apparently normative statements are actually trying to be
normative and are reasonable, has the intent of the document changed?
Even though I've written some portion of the language in the
document, I have mixed feelings about this issue. Some of the
apparently-normative statements I like and some I don't -- and I don't
know which ones I wrote, so that's not the issue.
Beyond being a summary of DKIM, the document also has become
something of a higher-level "system specification". As such, some of
the normative language really pertains to the higher-level integration
of DKIM into an operational email service and well could be extremely
useful for guiding design, implementation and deployment of DKIM. I
think that's a good thing, but I think we need to resolve whether this
document is making architectural, normative specification or whether it
is providing tutorial exemplars.
I think it would be fine to make this a standards-track document with
normative language.
I disagree. The purpose of an "Overview" is to give an informal summary of
the effect, and especially the reasoning and motivation for, a collection
of standards. So it may well outline what the standards do, and indicate
the sort of normative provisions they would make (which can include
indication of whether such provisions are MUST/SHOULD/MAY).
But it should include somewhere wording such as:
"This document provides an overview of the DKIM collection of related
standards, indicating how they are intended to work together to produce
[list of desirable effects]. But this document is not normative itself;
{RFCxxx], [RFCyyy] and [RFCzzz] should be consulted for the detailed
normative requirements."
--
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