OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sarif message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


Hm, interesting. Use of MUST in our case certainly doesn't conform to ISO's notion of it.

I see the following list of ISO acceptable alternates to SHALL NOT. Not sure whether any of these meet Stefan's criteria of being more accessible to non-native EN speakers.

is not allowed [permitted] [acceptable] [permissible]
is required to be not
is required that … be not
is not to be
need not
do not

Again, back to this specific issue. I wonder if we shouldn't inject a note that amplifies on the spec language (which refers to SHALL NOT). We'd want to emphasize that it is really not acceptable for SARIF to contain executable code but that due to lack of controls on user-input and/or guaranteeing the integrity of a SARIF file and the dangers of failure to sanitize, consumers can't assume that the spec has been met for this case. It is not acceptable for producers to inject executable code into SARIF markdown. It is not acceptable for consumers to fail to sanitize.

-----Original Message-----
From: David Keaton [mailto:dmk@dmk.com] 
Sent: Thursday, January 11, 2018 10:22 AM
To: Michael Fanning <Michael.Fanning@microsoft.com>; Larry Golding (Comcast) <larrygolding@comcast.net>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org
Subject: Re: [sarif] Re: SHOULD => SHALL in "Security implications"

      Before making this change, please consider what you want the future of this document to be.  If you think you might ever want to promote this to an ISO standard, you will want to avoid the word "must".

      ISO/IEC Directives Part 2 state: "Do not use 'must' as an alternative for 'shall'."  The reason is that "must" has a different meaning to ISO.

      You might want to keep these directives in mind in general, to protect future options for the document.

https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.iso.org%2Fsites%2Fdirectives%2F2016%2Fpart2%2Findex.xhtml&data=02%7C01%7CMichael.Fanning%40microsoft.com%7C61538e5664d1428e8ccd08d559203deb%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636512917367774225&sdata=%2FVnLhdXQDXrJ0pS0WmhSzSOdvN%2Bd%2FWRX9M8P3HtaF9Y%3D&reserved=0

					David

On 01/11/2018 10:14 AM, Michael Fanning wrote:
> Knowing your work as I do, I am confident you will give this a good think and make some appropriate changes.
> 
> I will say that for the specific case we're discussing (making the adjustment for banning potentially executable code from SARIF markdown), I like the clarity and additional emphasis that MUST provides.
> Michael
> 
> -----Original Message-----
> From: sarif@lists.oasis-open.org [mailto:sarif@lists.oasis-open.org] 
> On Behalf Of Larry Golding (Comcast)
> Sent: Thursday, January 11, 2018 9:56 AM
> To: 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org
> Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications"
> 
> 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
>>
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that generates this mail.  Follow this link to all your TCs in OASIS at:
> https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.o
> asis-open.org%2Fapps%2Forg%2Fworkgroup%2Fportal%2Fmy_workgroups.php&da
> ta=02%7C01%7Cmichael.fanning%40microsoft.com%7Cb57e78165e3746cb175508d
> 5591cd03b%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636512902664356
> 680&sdata=wRF4ZYCYMJO2wKem%2BW7L7irt8XFUp8H9lsgZKV%2FwIsc%3D&reserved=
> 0
> 



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]