ietf
[Top] [All Lists]

Re: 2119bis

2011-08-30 13:58:35
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
Description: S/MIME cryptographic signature

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf
<Prev in Thread] Current Thread [Next in Thread>