solid-contrib / test-suite

An automated test of Solid specification technical compliance
MIT License
23 stars 10 forks source link

Numbering of the new spec version #149

Open michielbdejong opened 2 years ago

michielbdejong commented 2 years ago

In https://gitter.im/solid/test-suite?at=62c31be79a314a3ec429310a Tim said that "[t]he plan is that the next version 0.9.1 will have the Insecure WebSocket notifications deprecated and secure authenticated web socket notifications added."

As I understand it, that would be a breaking change for clients (old clients will stop being spec compliant because they can no longer rely on receiving Insecure WebSocket notifications from storage servers) and also for storage servers (old servers will stop being spec compliant because they don't implement the new protocol).

However, reading the text, there is are two sections,

The non-normative section seems to contradict the normative one. And note that this spec text has been published (on GitHub) but has not been released (with a version tag) yet by the spec-writing team, so the current version of Solid is "v0.9.0, moving towards v0.9.1".

So in this current phase, we should probably consider the old protocol as required and the new protocol as optional. Once the spec-writing team tag and publish v0.9.1, we can maybe just switch those around, reporting on the new protocol as required and on the old one as optional.

michielbdejong commented 2 years ago

Thinking about the following changes:

We can categorise servers as:

  1. supporting 0.8 clients (don't enforce ath, accept insecure websockets, accept sparql-update PATCH)
  2. additionally supporting 0.9.0 (additionally accept text/n3 PATCH)
  3. additionally supporting 0.9.1 (additionally accept text/n3 PATCH and secure websockets)
  4. config option exists for rejecting 0.8.0 while still supporting 0.9.0 + 0.9.1 (enforce ath, no need to accept sparql-update PATCH anymore)
  5. config option exists for rejecting 0.8.0 + 0.9.0 while still supporting 0.9.1 (enforce ath, reject insecure websockets, no need to accept sparql-update PATCH anymore)

I think, off the top of my head, we have: