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

From: "sipcore issue tracker" <[email-masked]>
Date: Mon, 30 Aug 2010 18:33:19 -0000

#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.

-- 
Ticket URL: <http://trac.tools.ietf.org/wg/sipcore/trac/ticket/10>
sipcore <http://tools.ietf.org/sipcore/>

---

From: Dean Willis <[email-masked]>
Date: Mon, 30 Aug 2010 15:07:10 -0500

> #10: Convert all SHOULDs to 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

---

From: Hadriel Kaplan <[email-masked]>
Date: Mon, 30 Aug 2010 16:31:38 -0400

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

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 16:54:08 -0400

[ as individual, for now ]

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

MUST ... unless

is equivalent to using SHOULD and naming the only exceptions to 
conforming with the SHOULD. Using SHOULD ... unless would still run the 
risk that somebody would say the SHOULD still allows violation for 
arbitrary reasons.

So I agree that MUST ... unless is preferable to SHOULD.

	Thanks,
	Paul

> _______________________________________________
> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore
>

---

From: Mary Barnes <[email-masked]>
Date: Mon, 30 Aug 2010 17:03:54 -0500

We ended up changing alot of 4244 SHOULDs to MUSTs.  However, my
understanding on the use of MUSTs was that they shouldn't have
qualifiers. It's the SHOULDs that should have the qualifiers that
describe the circumstances under which it's okay not to do the SHOULD.
 So, I would prefer to keep the SHOULDs where we have valid
circumstances for not doing the should, but otherwise they should be
MUSTs (with no "unless...")  [If that makes any sense at all]. I'm
basing this on the text straight from RFC 2119:

1. MUST   This word, or the terms "REQUIRED" or "SHALL", mean that the
   definition is an absolute requirement of the specification.
...

3. SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

Mary.

On Mon, Aug 30, 2010 at 3:54 PM, Paul Kyzivat <[email-masked]> wrote:
> is equivalent to using SHOULD and naming the only exceptions to conforming
> with the SHOULD. Using SHOULD ... unless would still run the risk that
> somebody would say the SHOULD still allows violation for arbitrary reasons.
>
>>> 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".
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 30 Aug 2010 19:05:30 -0400

> basing this on the text straight from RFC 2119:

"MUST foo unless condition" is semantically equivalent to "if !condition 
then MUST foo". I'm pretty sure there is nothing wrong with the latter. 
As a result there shouldn't be anything wrong with the former either, 
but we can choose the preferred wording just to avoid making waves.

So, something like "Unless the SSP anonymizes all calls it MUST support 
temp GRUU".

>    carefully weighed before choosing a different course.

The distinction is understood, and still vague. Reasonable people differ 
greatly in what constitutes a "valid reason" even if they have carefully 
understood and weighed the full implications.

In practice it seems that many implementors treat SHOULD the same as 
MAY. And if they do, how can they be proven wrong?

I'm not quite ready (though tempted) to give up on SHOULD entirely. But 
I think the WG *SHOULD* have a *really* good reason for using SHOULD 
rather than MUST.

	Thanks,
	Paul