What is the difference in this case between SHOULD or MAY? On Aug 30, 2011, at 2:49 PM, Adam Roach wrote: > On 8/29/11 9:44 PM, Eric Burger wrote: >> Yes, and... >> >> I would offer that for most cases, If Y then MUST X or If Z then MUST NOT X *are* what people usually mean when they say SHOULD. In the spirit of Say What You Mean, a bare SHOULD at the very least raise an ID-nit, suggesting to the author to turn the statement into the if Y then MUST X or if Z then MUST NOT X form. Being pedantic and pedagogic: >> SHOULD send a 1 UNLESS you receive a 0 >> really means >> UNLESS you receive a 0, one MUST send a 1. >> >> My vision of the UNLESS clause is not necessarily a protocol state, but an environment state. These are things that I can see fit the SHOULD/UNLESS form: >> SHOULD send a 1 UNLESS you are in a walled garden >> SHOULD flip bit 27 UNLESS you have a disk >> SHOULD NOT explode UNLESS you are a bomb >> are all reasonable SHOULD-level statements. >> >> I would offer that ANY construction of SHOULD without an UNLESS is a MAY. > > > Eric. Put down the axe and step away from the whetstone. Here, I'll give you some text from RFC 3265 to mull. > > > deactivated: The subscription has been terminated, but the subscriber > SHOULD retry immediately with a new subscription. One primary use > of such a status code is to allow migration of subscriptions > between nodes. > > > Let's examine this use of "SHOULD." If the subscriber doesn't re-subscribe, is it an interop issue? No. > > Is it in the interest of the implementation to re-subscribe? Yes. At least, under most circumstances. Otherwise, they won't get the state change notifications they want. > > Are there cases in which it makes sense for the subscriber _not_ to re-subscribe? Yes, I'm sure there are. It's conceivable that the client happens to be shutting down but hasn't gotten around to terminating this particular subscription yet. But any such exceptions are highly implementation-dependent. Listing them would be useless noise to the reader, and senseless text creation for the author. > > Does "SHOULD" get abused by some authors in some documents? Of course it does. But your crusade to throw out a useful tool just because it has been misused on occasion is an extreme over-reaction. I like this tool. I use this tool. If you see people misusing it, slap them. > > But don't ban the tool. > > /a
<<attachment: smime.p7s>>
_______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf