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

["Elwell, John" <[e-mail]>]

 I tend to agree with Paul. If we say that whenever there are conditions you should use SHOULD rather than MUST, you will end up with very few MUSTs, since nearly every normative statement has some conditions behind it (either as part of the statement or implicit in what has gone before). I think we can probably make a distinction on whether those conditions can be clearly specified, or whether they are by their nature vague. For example, "SHOULD challenge for digest authentication, unless the recipient has other means of ascertaining the source of the request", versus "MUST challenge for digest authentication unless the request has been delivered over TLS".

John

> -----Original Message-----
> From: [e-mail] 
> [mailto:[e-mail]] On Behalf Of Paul Kyzivat
> Sent: 31 August 2010 00:06
> To: Mary Barnes
> Cc: [e-mail]; sipcore issue tracker; Hadriel Kaplan
> Subject: Re: [sipcore] #10: Convert all SHOULDs to MUST
> 
> 
> 
> Mary Barnes wrote:
> > 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:
> 
> "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".
> 
> > 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.
> 
> 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
> 
> > Mary.
> > 
> > On Mon, Aug 30, 2010 at 3:54 PM, Paul Kyzivat 
> <[e-mail]> wrote:
> >> [ as individual, for now ]
> >>
> >> Hadriel Kaplan wrote:
> >>> 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
> >>
> >>> -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
> >>> _______________________________________________
> >>> sipcore mailing list
> >>> [e-mail]
> >>> https://www.ietf.org/mailman/listinfo/sipcore
> >>>
> >> _______________________________________________
> >> sipcore mailing list
> >> [e-mail]
> >> https://www.ietf.org/mailman/listinfo/sipcore
> >>
> > 
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>