W3C home > Mailing lists > Public > public-coremob@w3.org > April 2012

Re: [coremob/level-0] df3f70: Replace incorrect use of "MUST [...] if available"...

From: Tobie Langel <tobie@fb.com>
Date: Wed, 18 Apr 2012 12:47:43 +0000
To: Cuihtlauac ALVARADO <cuihtlauac.alvarado@orange.com>, "public-coremob@w3.org" <public-coremob@w3.org>, James Graham <jgraham@opera.com>
Message-ID: <CBB47C98.7A303%tobie@fb.com>
On 4/17/12 3:51 PM, "Cuihtlauac ALVARADO" <cuihtlauac.alvarado@orange.com>

>Hi Tobie,
>Allow me to express my disagreement with respect to that change, and
>such kind of change in general.
>I share your interpretation of RFC 2119. "MUST" is an unconditionally
>requirement while "SHOULD" is a conditional requirement (i.e. "there may
>exists valid reasons [...] to ignore [...]"). Replacing "MUST if" by
>"SHOULD" is formally correct. However, in practice, "MUST if" is far
>superior to "SHOULD", the former should be preferred. Let me explain why.
>Basically, the "MUST if" clause comes with text which details the
>circumstances under which the requirement does apply, while "SHOULD"
>does not. In our case, we absolutely do not want a device which has a
>SMS app and the agent is *not* capable to trigger that SMS app using the
>sms: scheme. That must be avoided. We really want the URI scheme to be
>dispatched always, unless sending SMS is not possible. This was captured
>by "MUST ... (if available)", it is no longer by "SHOULD".
> From test implementation perspective, the "MUST if" is easily turned
>into a real conditional statement, in contrast, it is impossible to
>decide, at test execution time, whether failing to comply with a
>"SHOULD" is actually valid or not.
>In practice, "SHOULD" and "MAY" are the same. "MAY" is good for options.
>When "MUST" has valid exceptions, positive cases should be detailed in
>"MUST if" sentences. "SHOULD" MUST be avoided ;-)

I don't have a strong opinion about this.

James Graham requested that change so I'll let you too fight over it. :)

Received on Wednesday, 18 April 2012 12:48:44 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:05:45 UTC