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

[Hadriel Kaplan <[e-mail]>]

Right, I didn't mean just make them MUST without qualifiers - "MUST ... unless ..." is fine.

-hadriel

On Aug 30, 2010, at 4:07 PM, Dean Willis wrote:

> 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