RE: [sarif] Re: SHOULD => SHALL in "Security implications"

["Larry Golding \(Comcast\)" <larrygolding@comcast.net>]

Stefan,

That's an interesting suggestion. Please open an issue in the GitHub repo and I will consider it.

For those of you who aren't familiar with RFC 2119, both SHALL and SHOULD (and, for that matter, REQUIRED) are permitted when expressing an absolute requirement. There are places in the spec where "SHALL" sounds better to me, other places where "MUST" sounds better to me, and still other places where they sound equally good to me.

For example, consider this sentence from §3.2:

        Two URIs SHALL be considered equivalent if their normalized forms are the same...

To my ear, MUST does not sound as good here. I'm not sure I can fully explain why. I think it is because in English, "MUST" has more of a feeling of "telling someone what to do". SHALL is more impersonal. If I write "Two URIs MUST be considered equivalent..." it sounds (to me) like a parent telling a child that they "must clean up their room". It sounds like a command, rather than a simple description of how the world has to be.

I tend to use MUST in requirements that describe a syntactic constraint. For example, consider this sentence from §3.4:

        Unless otherwise specified in the description of a specific property, all properties whose values are of type "string" MUST have a non-empty value.

Again I can't fully explain why. I think it's because here, I'm telling the string how to behave, and I don't have any trouble giving commands to a string 😊

But looking over the spec, I see that I'm not consistent about that. For example, in §3.7.2.1:

        If a property bag contains a property with the name tags, then the value of that property SHALL be an array containing zero or more arbitrary strings...

So again, please file an issue and I'll think about it. I understand that when writing for an international audience, I MUST 😊 ensure that the text is as clear as possible. In some cases, I might have to choose between text that is as pleasing and natural as possible to a native English speaker, and text that is more understandable to a non-native speaker.

Thanks,
Larry

-----Original Message-----
From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org] On Behalf Of Mr. Stefan Hagen
Sent: Thursday, January 11, 2018 9:11 AM
To: sarif@lists.oasis-open.org
Subject: [sarif] Re: SHOULD => SHALL in "Security implications"

Dear members,

I hereby suggest we use MUST NOT instead of SHALL NOT.

SHALL and SHOULD have an unnecessary small Levenshtein distance ;-)

It also challenges some non-native readers more than required.

With MUST all is so much clearer, isn't it :-?

All the best,
Stefan.
On 11/01/18 16:32, Michael Fanning wrote:
> Thanks, Larry. I agree this is the right thing to do.
> 
> Nice catch, Jim. Security is important. 😊
> 
> Michael
> 
> *From:* sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org]
> *On Behalf Of *Larry Golding (Comcast)
> *Sent:* Wednesday, January 10, 2018 1:31 PM
> *To:* sarif@lists.oasis-open.org
> *Subject:* [sarif] SHOULD => SHALL in "Security implications"
> 
> In this morning’s meeting, Jim moved, and it was agreed, to replace 
> “SHOULD NOT” with “SHALL NOT” in one of the bullet points in the 
> “Security implications” section. Upon re-reading that section, I think 
> it best to replace /all/ SHOULDs with SHALLs, and /all/ SHOULD NOTs 
> with SHALL NOTs, in that section.
> 
> I’m going to make those changes in the Provisional Draft I’m now 
> working on. If anyone please disagrees, please respond to this 
> message, and I will file a bug in the GitHub repo so we can discuss it further.
> 
> Thanks,
> 
> Larry
>