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@xxxxxxxxx> 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@xxxxxxxx
https://www.ietf.org/mailman/listinfo/ietf