John C Klensin wrote:
--On Wednesday, August 31, 2011 23:10 -0400 Sam Hartman
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.
I like those terms, Tentative, Provisional, perhaps also Exploratory,
But consider, if SHOULD [NOT] was to be abolished, wouldn't MUST [NOT]
now be redundant and implied in functional and technical semantics?
It seems it will reduce to usages of key words such as: IMPLEMENT,
USE, NEGOTIATE, IFF, DON'T, CAPABLE, DEPEND and perhaps PLEASE and
PLEASE IMPLEMENT X, Y, Z. PLEASE NEGOTIATE for X first and PLEASE
USE Y IFF peer implementators are not CAPABLE of Z.
IMPLEMENTATION NOTE: PLEASE DON'T DEPEND on X, Y, or Z if
peer implementation are not capable of X, Y or Z.
Jokes to the side, IMO, I don't see how it would be possible to impose
things on implementators deciding on items that are not necessary,
overdone, "candy" and perhaps Pareto's principle comes into play - It
works 100% of the time for the minimum required which represents 80%
of the total capabilities.
The situation here appears to be features in the remaining 20% now
become more necessary overtime and in hindsight, we see there are a
lot "Oops" that didn't make those things part of the minimum
Will any future rewording of "compliance" docs change this or make it
better? I don't seem to think so because as we all know, perfection
is not possible - we need to have those knobs and switches. Making
everything a MUST [NOT] or wording things to steer people to 100%
implementation will most like raise the adoption barrier and and we
end up relaxing things anyway just to get people to consider an RFC.
Ietf mailing list