Exactly. I'm working my way through RFC2616bis, trying to distinguish between SHOULDs that actually have implications for interoperability and SHOULDs that are just there because the english word 'should' happened to make sense at the time. It's a huge pain. On 31/08/2011, at 5:42 PM, Eric Burger wrote: > Interesting example. I like it. I agree that when to retry is not at all a protocol issue. That probably is why we are in fuzzy land, and this highlights why SHOULD is bad. The availability of SHOULD drew the author of the mentioned RFC to mix a user interface / user experience issue with a protocol issue. > > Saying a client SHOULD retry immediately, to migrate subscriptions, is an implementation detail and has absolutely NOTHING to do with the protocol. > > It would be OK to have a NOTE in the protocol RFC discussing that "deactivated" is an opportunity to migrate the subscription. It would be OK to have an Informational implementor's guide that notes that it would be good for clients to leverage the "deactivated" state to quickly migrate a subscription. However, there is NOTHING in the protocol to say SHOULD. > > On Aug 30, 2011, at 3:15 PM, Adam Roach wrote: > >> In this case, unless the implementation has a good reason, failing to re-subscribe will result in behavior that the user perceives as broken. I don't think that's really "MAY" territory. >> >> /a >> >> >> On 8/30/11 1:57 PM, Eric Burger wrote: >>> 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 >> >> _______________________________________________ >> Ietf mailing list >> Ietf@xxxxxxxx >> https://www.ietf.org/mailman/listinfo/ietf > > _______________________________________________ > Ietf mailing list > Ietf@xxxxxxxx > https://www.ietf.org/mailman/listinfo/ietf -- Mark Nottingham http://www.mnot.net/ _______________________________________________ Ietf mailing list Ietf@xxxxxxxx https://www.ietf.org/mailman/listinfo/ietf