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