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: SHOULD => SHALL in "Security implications"

Thank you Katrina!

for not letting me stand there alone in that language corner :-)

Sometimes we are reminded, that the world is not switching to English, 
and the British and Americans do not have to fight against or for 
extra "u" letters and the like or the order of er vs. re in word endings
or what exactly expiry means ...

*but* the world is forming a new language starting from English! ... 
and as spec writers introduce meta languages like the MUST et al. 
on top.

In OASIS and IETF we use RFC 2119 as updated by RFC 8174 - or 
like every fresh workproduct will have in the boilderplate / frontmatter:

1.2 Terminology
The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, 
this document are to be interpreted as described in [RFC2119] and [RFC8174].

esp. the "[] only UPPERCASE usage of the key words have the defined 
special meanings." part in RFC8174 emphasizes, that this is not 
natural language.

I always understood this as highlighting or tagging with a code.

Clear understanding for implementers in exactly these situation 
where (we) the spec writers point out something via MUST, SHOULD 
or MAY justifies breaking the "reading flow".

Could we maybe also try to white instead of blacklist where possible 
(which would help the reader a lot, as every "not" or "NOT" comes as 
an extra evaluation task :-)

For me a spec that utilizes more than these three dimensions (MUST, 
SHOULD, MAY) is suspicious at least provoking the question if another 
spec staying with these three terms would lead to better interoperable 
and conforming implementations.

I would suggest to focus on what we want and serve the OASIS rules, 
as OASIS is a public accepted submitter to ISO and with OData as an 
example, we had no trouble after we made the OASIS Standard stage, 
to also submit unchanged to ISO, fill in a form, where OASIS stated, 
that the TC would continue to work on future versions, and then we 
waited for the many months election period and the bunch of OData 
standards was concat and wrapped as i  and is now an ISO standard - 
for free. 

And much clearer in my opinion as with some IEEE -> ISO standards, 
where to me accessibility and status of the originating IEEE standards 
is not always clear, the OASIS OData standard documents are still the 
accepted, and best navigateable form to "use" it ...

If you guys with native English reading capabilities perceive hurt 
when reading clumsy UPPERCASED terms (MUST vs. SHALL) like Laurence 
explained very well, IMO we should find a way that is good for the 
group, easy to read and understand for all.

What I would be very reluctant to follow are below (or in other 
mails of this thread) noted specific differentiations in effective 
meaning of (RFC 2119 synonyms) i.e. I want to preserve:
relations ... 

I wrote this in a (small) browser rendered html "textarea", so 
albeit I wrote this mail a few times before sending, some hard to 
understand text may have slipped through, and if so, I already feel 
sorry for that.

All the best,
On 12/01/18 06:44, O'Neil, Yekaterina Tsipenyuk wrote:
> 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.

> ... [ -- - 8< - -- ]

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