Sam Hartman wrote:
"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.
Eric, I was referring to the implementation level where one can afford
to make streamlining decisions overtime when options become stable and
never change its state. It can be removed to make things easier out of
the box, but I would not not propose it as a spec change.
Beside the obvious backward compatibilities issue, changes can be
leverage to perform different functional needs than what was not the
One real example is with SMTP just recently realized how a SHOULD to
MUST change has been leveraged.
STD10 has a SHOULD NOT drop connection before QUIT negotiated, changed in
RFC2821 (now RFC5321) to a MUST NOT.
We are observing a lost of CPU idle time and resources (channels)
consumption with anonymous clients intentionally holding connections
open while for additional mail transactions to arrive and send. The
only receiver defense to control the abuse is to violate RFC5321 by
dropping the client after the first transaction.
Note: No intent to highlight this issue, just an example of changing a
SHOULD to a MUST not necessarily due to long term stabilization, but
for new functional needs have repercussions.
Ietf mailing list