Re: [sipcore] #10: Convert all SHOULDs to MUST

[Dean Willis <[e-mail]>]

On 8/30/2010 1:33 PM, sipcore issue tracker wrote:
> #10: Convert all SHOULDs to MUST
> ------------------------------------+---------------------------------------
>   Reporter:  hkaplan@…               |       Owner:
>       Type:  enhancement             |      Status:  new
>   Priority:  major                   |   Milestone:  milestone1
> Component:  rfc4244bis              |     Version:  2.0
>   Severity:  In WG Last Call         |    Keywords:
> ------------------------------------+---------------------------------------
>   I know this isn't something we have a rule for, but ISTM that "SHOULD" is
>   a dirty word.  We get into trouble every time we have a SHOULD, and this
>   draft has a lot of them.  Either it's a MUST, or it's not.  I recommend we
>   change them all, or at least explain about why they're not MUST.
>


Better yet, every usage of RFC 2119 language (SHOULD, MUST, etc.) MUST 
contain an explanation of why that particular RFC 2119 keyword was used 
and and what the consequences of failing to implement according to the 
specification are. For example, in this case we selected MUST because of 
the well-known fact that failure to explain requirements in a protocol 
specification results in lazy implementations that ignore the 
requirements because the implementers do not understand the implications 
of having done so. This is exacerbated by having too many RFC 2119 
requirements statements in general. If the requirements are hard to 
meet, they should be harder to make; that is, the task of creating such 
a requirement properly includes thoroughly documenting the requirement.

There are places where a SHOULD is appropriate, and the semantic is 
"MUST except when a predicted but infrequent condition, as described 
herein, is detected".

So, perhaps we could begin writing SHOULD requirements as "MUST, except 
when... because .... occurs or may occur if this requirement is not met."

--
Dean