Marc Petit-Huguenin wrote:
The meaning of SHOULD is clear for the authors (it "mean[s] that there
may exist valid reasons in particular circumstances to ignore a particular
item, but the full implications must be understood and carefully weighed
before choosing a different course."), the problem is that some
implementers use a different meaning
No, it just means that some implementors follow the spec _to_the_letter_
and apply _their_ very own and very personal decision ("carefully weighed").
It should be pretty obvious that the definition is explicitly written
in a fashion that different implementors are be expected to come up
with different decisions based on their specific requirements and
environments.
SHOULD / RECOMMENDED is used in RFCs for just about everything between
a MAY that is considered useful by some (or at least the document author)
and something that is close to vital for the general use case but
dispensible in some specific usage scenario.
Hector <sant9442(_at_)gmail(_dot_)com> wrote:
STD10 (RFC821) has a SHOULD NOT drop connection before QUIT is
negotiated, and it was changed in RFC2821 to a MUST NOT.
[...]
Even with all those warnings from the smart clients leveraging the
delays, its ignored and increasingly happening and that server
defensive prediction is starting to come true - by selectively
ignoring the one RFC2821 MUST NOT drop connection mandate and
selective using STD10 SHOULD NOT which RFC2119 says is an option, you
don't need to follow it.
I don't understand why this was changed, and I would very probably
deliberatly ignore that MUST NOT drop if I ever had to implement this.
When dealing with network connections, a dropping of the network
connection can *ALWAYS* happen, so rather than specifying
ostrich-like behaviour, the protocol should have been defined
to handle this situation gracefully. And it really doesn't matter
whether the connection dropped to a network malfunction, endpoint
malfunction, attack or an act of self-defence for an unexpectedly
long delay or timeout.
-Martin
_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf