Dave Crocker wrote:
Michael Thomas wrote:
said, there's a fair amount of Orwell floating around about
making a request into a command without benefit of royalty.
There are two problems with the attempt to dismiss the import of the
specification's style of directing receive-side behavior:
1. Specification is specification
When a document has normative language that directs behavior, it
directs behavior. While the difference among may, must, and should is
intended to be significant, we have no empirical basis for knowing
exactly what difference they have among implementers and operators. We
certainly have no empirical basis for knowing the impact of a normative
assertion in a specification like SSP, because SSP is operates in a
semantic realm for which the IETF has no precedent.
2. IETF standard-track status carries its own level of force. When an
IETF standard-track specification calls for a behavior, its impact
depends upon basic adoption of the specification. That is, the mere
presence of approval lends weight to every aspect of the document's
content. While one or another working group participant might impart
more or less casualness to the language, we need to consider what
average readers will see, in the context of basic standardization. We
need to particularly consider this for normative language that pertains
to basic mechanisms within SSP. For example, if the reader imparts any
credibility to the handling directives at all, they are pretty much
forced to treat the MAY as, at least, a SHOULD.
My position is that these new dispositions directives should be
removed, and that the discussion of sender desire should be moved
to non-normative discussion in the practices (eg, "strict"). I'd
even be happy with removing them altogether though Scott's experience
with SPF is well taken.
Mike
_______________________________________________
NOTE WELL: This list operates according to
http://mipassoc.org/dkim/ietf-list-rules.html