[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: comments on draft
|
I filed this as Issue #376: @kupsch feedback responses â fixed the small issues (except for one where the spec is correct as it stands), â pushed a change draft: â merged it into the provisional draft: â filed issues for the two substantive items:
â labeled Issue #376 as
resolved-fixed, â and closed it. Thanks, Larry -----Original Message----- Jim, Thank you for reading the changes. I'll address these issues later this afternoon. Larry -----Original Message----- From: James Kupsch <kupsch@cs.wisc.edu> Sent: Monday, April 15, 2019 12:31 PM To: Larry Golding (Myriad Consulting Inc) <v-lgold@microsoft.com>;
sarif@lists.oasis-open.org Subject: Re: comments on draft Larry, I reviewed the changes that you made in the document sarif-v2.0-issues-366-367-369-370.docx and have a couple of comments on the changes, and two other clarifications that should be made. Jim -------------------------------------------------- p.16 1.2 Terminology - artifact definition Although a database can be accessed via a URL, the URL is really an artifact on the web server that happens to map to a database table, so only indirectly is it a database table. -------------------------------------------------- p.36 3.10.1 General "location of the file at the time" -> "location of the artifact at the time" "For additional normalization requirements for URIs that use the "file"
scheme ..." -> "file scheme URI normalization SHALL use a modified version of RFC 3986 described in the next section ..." -------------------------------------------------- p.37 3.10.2 URIs that use the file scheme Change section name to "Normalizing file scheme URIs" Add after list item 2: "Remove empty path segments" -------------------------------------------------- p.39 3.11.3 Plain text messages "Lline" -> "Line" -------------------------------------------------- p.181 Appendix D (Normative) Production of SARIF by converters "version [SEMVER]" -> "version [SEMVER]" -------------------------------------------------- p.181 Appendix D (Normative) Production of SARIF by converters The clause "but SHOULD NOT attempt to populate result.analysisTarget"
should be removed, as for many tools the analysisTarget is known ================================================== A couple of other clarification that I think should be made -------------------------------------------------- p.29 3.4.5 index property There should be a mechanism to redact multiple baseUriIds, but still allow them to be different directories in the file system. If the redactionToken is used then there needs to be a note that if the redactionToken is present in segment,
then each use within a uri should be considered a unique (undisclosed) location in the file system, just like a uri with '..'. If the redactionToken appears in a baseUriId's uri then the baseUriId should be treated as if it were a unique (undisclosed) directory location, but all uses of the that baseUriId with the redacted segment should be considered to have the same unique (undisclosed) path prefix. For instance if the redactionToken is "[REDACTED]", and a baseUriId named X has a uri of "[REDACTED]", then {baseUriId="X", uri="f.c"} and {baseUriId="X", uri"f.c"} are the same path, whereas {uri="[REDACTED]/f.c}
and {uri="[REDACTED]/f.c} should not be considered the same path. An alternative would be to allow an index of -1 to indicate redaction. -------------------------------------------------- p.147 response object The response object should have a mechanism to indicate that no response was received from the server. This could happen due to a DNS failure or a connectivity issue such as the server not running or the host or port being inaccessible.
Should add a requestFailed and requestFailureReason at a minimum. This is similar to an invocation where to process creation failed. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]