Re: 2119bis

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(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf