--On Wednesday, August 31, 2011 23:10 -0400 Sam Hartman
"Eric" == Eric Burger <eburger(_at_)standardstrack(_dot_)com> writes:
Eric> This highlights an interesting issue as an RFC goes
from PS to Eric> IS. I would offer that most SHOULDs in a
document will, if Eric> there are real implementations out
there, migrate to MUST or Eric> MUST NOT.
Eric> On Aug 31, 2011, at 9:57 AM, hector wrote:
Hmm. Most of the times I use SHOULD I'd expect them to stay
SHOULD. SHOULD doesn't mean "this feature is desired," it
means "do this unless you have justification for doing
something else." There are a few cases (new algorithms) where
you mean SHOULD+ (we'll move to MUST in the future) but often
you mean do this unless you're in a constrained environment,
or you know you won't need it or something like that. In those
cases, SHOULDS tend to stay SHOULDS.
Exactly right. Indeed, if I agreed with Eric's view, I'd think
we should abolish SHOULD and SHOULD NOT (almost) entirely,
replacing them with temporary qualifications for MUST that would
convey "not quite sure about this yet, but MUST is certainly our
intention". "Tentative" or "Provisional", with appropriate
IETF-specific definitions, would be two such words.
Note that this loops back to the the discussion about
conformance and certification. The standards bodies whose
principal concerns about about conformance and certification
cannot use what we call SHOULD because one cannot build a
conformance test around a case that might have exceptions,
especially exceptions that are not completely enumerated. They
can, and do, use what we periodically describe with language
like "MUST implement but are not required to configure in
operation" (and, to add to the confusion, sometimes call that
"SHOULD use"), but the conformance test then checks only for the
implementation and, perhaps, for the presence of the knob.
Ietf mailing list