Re: SHOULD vs MUST

fwiw -

I have, for many SIPits (a rather large interop event for SIP  
implementations) worked to get the people writing code from these  
documents to understand that MUST means MUST and SHOULD means MUST ... 
(very long pause)... unless you _really_ know that not following the  
SHOULD won't result in very bad things.
They typically respond with MUST means MUST unless they're sure they  
can get away without it most of the time, and that SHOULD means its in  
some future release that will get funding maybe someday. Some of that  
response is tongue-in-cheek - some of it isn't.
I see a strong trend for unadorned SHOULDs to remain unimplemented.  
SHOULDs that have a very clear, and explicitly called out even when  
they seem incredibly obvious, explanation of the bad things that can  
happen if you don't follow them get implemented.
So, at least for the documents I edit, I work really hard to explain  
the SHOULDs to help motivate the implementors to actually build things  
that conform to it.
RjS



On Jun 25, 2008, at 12:02 PM, Scott Brim wrote:

> On 6/25/08 8:24 AM, John C Klensin allegedly wrote:
> > --On Wednesday, 25 June, 2008 07:59 -0400 Scott Brim
> > <swb(_at_)employees(_dot_)org> wrote:
> > > ... and draft authors should include explanations in their
> > > drafts of the reasons an implementor might legitimately have
> > > for not implementing the "should".  For example, an older
> > > operating system that does not support a new capability.
>
> > Do you really mean, e.g., 	... where feasible and, in the author's  
> > judgment,
> >         appropriate, it is desirable to include explanations or
> >         illustrations of the exception cases in drafts that use
> >         SHOULD.
> > ???
> > I've run into a number of situations over the years in which
> > there are known edge cases that prevent a MUST but where those
> > edge cases are rare and obscure enough that describing them
> > would require extensive text.
> My rule of thumb is: when you're writing the draft if something is  
> not a MUST, ask yourself "why not?" and write down your answer.  You  
> can be brief but make it clear that the SHOULD is a MUST with  
> exceptions.
> There's no way we should have strict process rules about this.  The  
> IETF has enough rules as it is.  However, explanations of SHOULDs do  
> make better standards.  The point is to give guidance to  
> implementors.  I did an informal survey last year and found that  
> some implementors treat every SHOULD as a MUST, but more of them  
> just treat a SHOULD as a MAY, essentially to be ignored.  An  
> explanation of the circumstances surrounding a SHOULD will lead to a  
> lot more consistency in implementation.  Many SHOULDs in RFCs are  
> because there are old implementations that need to be taken into  
> account, or because some capability isn't widely possible yet but  
> will be within the lifetime of the standard.  If a MUST becomes a  
> SHOULD to take that into account, and you explain it, your chances  
> of getting rid of non-MUST-capable implementations eventually goes  
> up tremendously.  So, to reiterate, when you're writing the draft if  
> something is not a MUST, ask yourself "why not?" and write down your  
> answer.
>
> _______________________________________________
> 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