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
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
