OASIS Static Analysis Results Interchange Format (SARIF) TC

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.

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

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

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. http://www.iso.org/sites/directives/2016/part2/index.xhtml 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

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

David, thanks for that information. I'll add it to my TODO list to revisit that ISO Directives document (I read it once, a year ago, when we were considering taking SARIF to ISO), and then I'll respond back to this thread with a proposal. Larry
Original Message----- From: Michael Fanning [ mailto:Michael.Fanning@microsoft.com ] Sent: Thursday, January 11, 2018 10:40 AM To: David Keaton <dmk@dmk.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" 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

(and Michael, I'll add it to my TODO least to add, as a "NOTE", the stronger language about security.)
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 12:07 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications" David, thanks for that information. I'll add it to my TODO list to revisit that ISO Directives document (I read it once, a year ago, when we were considering taking SARIF to ISO), and then I'll respond back to this thread with a proposal. Larry
Original Message----- From: Michael Fanning [ mailto:Michael.Fanning@microsoft.com ] Sent: Thursday, January 11, 2018 10:40 AM To: David Keaton <dmk@dmk.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" 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

Sounds good. All this reminds me that we need to be sure not to drop the suggestion made by the working group to consider how SARIF files might be signed to ensure they haven't been tampered wi Issue #47 in the repo. https://github.com/oasis-tcs/sarif-spec/issues/47th .
Original Message----- From: Larry Golding (Comcast) [ mailto:larrygolding@comcast.net ] Sent: Thursday, January 11, 2018 12:22 PM To: Michael Fanning <Michael.Fanning@microsoft.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications" (and Michael, I'll add it to my TODO least to add, as a "NOTE", the stronger language about security.)
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 12:07 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications" David, thanks for that information. I'll add it to my TODO list to revisit that ISO Directives document (I read it once, a year ago, when we were considering taking SARIF to ISO), and then I'll respond back to this thread with a proposal. Larry
Original Message----- From: Michael Fanning [ mailto:Michael.Fanning@microsoft.com ] Sent: Thursday, January 11, 2018 10:40 AM To: David Keaton <dmk@dmk.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" 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

Good catch. I defined a new label in the repo, "required", and I tagged Issue #47 with it. We can use it to identify the things we have to do before we send out a draft for comment. Larry
Original Message----- From: Michael Fanning [ mailto:Michael.Fanning@microsoft.com ] Sent: Thursday, January 11, 2018 1:12 PM To: Larry Golding (Comcast) <larrygolding@comcast.net>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications" Importance: Low Sounds good. All this reminds me that we need to be sure not to drop the suggestion made by the working group to consider how SARIF files might be signed to ensure they haven't been tampered wi Issue #47 in the repo. https://github.com/oasis-tcs/sarif-spec/issues/47th .
Original Message----- From: Larry Golding (Comcast) [ mailto:larrygolding@comcast.net ] Sent: Thursday, January 11, 2018 12:22 PM To: Michael Fanning <Michael.Fanning@microsoft.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications" (and Michael, I'll add it to my TODO least to add, as a "NOTE", the stronger language about security.)
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 12:07 PM To: 'Michael Fanning' <Michael.Fanning@microsoft.com>; 'David Keaton' <dmk@dmk.com>; 'Mr. Stefan Hagen' <stefan@hagen.link>; sarif@lists.oasis-open.org Subject: RE: [sarif] Re: SHOULD => SHALL in "Security implications" David, thanks for that information. I'll add it to my TODO list to revisit that ISO Directives document (I read it once, a year ago, when we were considering taking SARIF to ISO), and then I'll respond back to this thread with a proposal. Larry
Original Message----- From: Michael Fanning [ mailto:Michael.Fanning@microsoft.com ] Sent: Thursday, January 11, 2018 10:40 AM To: David Keaton <dmk@dmk.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" 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

As a non-native speaker, I have to say I had to pause for a second to think about what the proposal of changing SHOULD to SHALL means. I did infer the meaning of the change correctly, but I think it was mainly due to the fact that the attention was drawn to making this change. That is, if I was just reading the final version of the spec, I would have not picked up on the connotation. I think the options listed below would not cause a confusion for me though. k
Original Message----- From: sarif@lists.oasis-open.org [ mailto:sarif@lists.oasis-open.org ] On Behalf Of Michael Fanning Sent: Thursday, January 11, 2018 10:40 AM To: David Keaton <dmk@dmk.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" 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