Re: 2119bis

Yes, but there is another factor that appears to be presumed in thediscussions that might will help explains the critical difference:


    Even if SHOULD is interpreted as a MUST IMPLEMENT,
    there is no MUST USE guarantee by protocol consumers.

An implementator might decide a particular SHOULD has an absolute noconsumer value, it might even be harmful, and it might be a lowadoption currently, that might be enough to ignore it.

On the hand, if he says "Oh, lets add it anyway," he must stillpresent it as OPTION to the consumer for them to decide.

In my view, SHOULD are user protocol options to set. Odds are good aSHOULD would be enabled out of the box. Some might be disabled out ofthe box. If its not an user option, then that means it must beenabled with no way to turn off. If so, then logic tells me that thisSHOULD should of been a MUST to be begin right. No?


--
HLS


Eric Burger wrote:

My interpretation of what you wrote is that in your mind there is absolutely no 
difference between a SHOULD and a MAY.  They are both optional, and you 
implement whatever you have time to implement, with SHOULD's prioritized higher 
than MAY's.

Even if that is not what you mean, it is what many implementors do.

I would offer this highlights the problem with today's SHOULD.  Some think 
SHOULD means something is OK to implement, but life does not end if you do not 
do it. Others think SHOULD means something HAS to be implemented, unless the 
environment indicates the protocol will not work in some corner case.


On Aug 30, 2011, at 3:08 PM, hector wrote:

When I approach a protocol to implement, the first thing I typically do is extract and 
develop the basic wiring of the protocol, the minimum requirements.  Make sure the basic 
framework is correct 100%, then I look for the SHOULDs and also MAYS which are the 
easiest to add.  I look at the SHOULD by order of importance and also complexity.  How 
much "CANDY" is it?  It is a security feature?  What are the other 
implementation requirements, tools, APIs, etc.  Generally I want to get security out the 
way.  Its like SMTP AUTH - its not required but anyone cleaning up and rewriting an SMTP 
spec today, might include the AUTH extension as a SHOULD. And implementators are keen to 
the importance of it.  But nothing won't break down if you don't, less functionality but 
the basic structure is still there.

Its the same approach used for all the protocols we support. Start with the 
basics and then add on  as necessary.

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



------------------------------------------------------------------------

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf

_______________________________________________
Ietf mailing list
Ietf(_at_)ietf(_dot_)org
https://www.ietf.org/mailman/listinfo/ietf