Security considerations

[gkellogg]

• Update security considerations based on work in N-Quads. Fixes zero current implementations of Turtle/TriG/N-Triples/N-Quads functionality are spec compliant, because none can "ensure that malignant strings may not be used to mislead the reader" — there's just no way to do so! #11.
• Update issue on IRI to Revise terminology to align with current RFCs. #15.
• Add informative section on the rdf:JSON datatype for Add the rdf:JSON datatype #14.

---

Preview | Diff

[TallTed]

Most are minor. SHOULD prevent is little better than MUST prevent, as that prevention remains an impossibility, and we should get away from specifying such an impossibility sooner than later.

[pfps]

This PR makes substantive changes that need discussion in the WG.

[domel]

One does not exclude the other. I don't see why blocking this PR, there is a corresponding box with information in places for WG discussions.

[pfps]

I don't think the WG has even voted to take up this sort of change to RDF.

[gkellogg]

This PR makes substantive changes that need discussion in the WG.

Can you be more specific? It includes issue markers, and extracts the security considerations from the mime type to its own section, which is called for in publishing standards. We have been working to correct issues in the security consideration section to address various issues. This text is used in a number of specs. Do you think the full WG needs to resolve to make changes to security considerations?

issue markers are not normative changes, but serve as cues to readers about issues under discussion that may lead to changes in future versions.

[pfps]

There are three separate changes in this PR. Security, IRIs, and JSON. I'm not aware that the WG has decided to consider any of them. I don't see any open issues at https://github.com/w3c/rdf-star-wg/issues where these changes could fit.

[gkellogg]

There are three separate changes in this PR. Security, IRIs, and JSON. I'm not aware that the WG has decided to consider any of them. I don't see any open issues at https://github.com/w3c/rdf-star-wg/issues where these changes could fit.

Generally, these are related to errata, or the consequences of dealing with the errata.

• Security Considerations is an issue for spec-track documents, as is Privacy Considerations. This is more a matter of moving text which involves making reasonable updates.
• IRIs have been problematic due to the lack of progress on RFC3987 when prevents it from being normatively cited. We need to do something here, and issue Revise terminology to align with current RFCs. #15 is open to try to figure that out. In the mean time, an issue marker tells the community that it's being considered.
• rdf:JSON is not an erratum, but it's been considered good practice to put issue markers in drafts about open issues.

It sounds like you think that the chairs need to set a policy on the scope of editorial changes related to dealing with errata and updated requirements for spec-track documents.

[TallTed]

It sounds like you think that the chairs need to set a policy on the scope of editorial changes related to dealing with errata and updated requirements for spec-track documents.

Without speaking to the specifics of this PR (#16) or the discussion on it, I would suggest that keeping each PR (and each preceding Issue) to a single topic — by which I mean a single erratum when addressing errata from the previous spec — will be a better practice than mushing several topics/errata together, as is being done here.

[gkellogg]

Generally, adding issue markers for open issues has been considered good practice, at least in groups I've been involved with. When doing a PR keeping the active issues listed in the spec was considered useful. However, here it seems to have become contentious.

I've removed the updated wording on the #15 and new issue marker for #14 to focus solely on the update to security considerations.

[TallTed]

Generally, adding issue markers for open issues has been considered good practice, at least in groups I've been involved with. When doing a PR keeping the active issues listed in the spec was considered useful. However, here it seems to have become contentious.

If this PR were just adding issue markers for open issues, I think there would have been no contention. However, it was adding those markers and making other changes to the content, which mix was unsurprisingly (to me) contentious...

[afs]

The issue markers take the description from the issue.

But initial descriptions have been containing opinion and proposal and then do not reflect dicussion in the issue.

Here we have "Update issue on IRI to #15." Nothing to do with security considerations.

[TallTed]

@afs wrote:

The issue markers take the description from the issue.

But initial descriptions have been containing opinion and proposal and then do not reflect dicussion in the issue.

Here we have "Update issue on IRI to #15." Nothing to do with security considerations.

Yes. This is another reason why (as I've noted elsewhere) I would prefer there to be one concern per Issue, and one Issue per PR, and to have meaningful naming and description of both Issue and PR. The initial Issue description need not be revised to reflect subsequent discussion, so long as it is a simple description of the concern with neither personal opinion nor proposed solution.

[gkellogg]

@afs and @pfps, you both have outstanding changes requested that prevent merging this PR. Can you please either approve, or suggest additional changes?

This version should closely match that in w3c/rdf-n-quads#19 which has approvals.

[pfps]

The changes here now appear to be much better limited. The only problem is that the commit list has a lot of other stuff in it. It would be better to squash all the commits into one when merging or squash locally and force-push.

[gkellogg]

My practice has been to do squash merges when there are more than a couple of commits.

A force push may become necessary if there are any conflicts with other PRs, but probably the time to quash is when ultimately merging the PR.