Version 0.8 Changelog

[michielbdejong]

I think now is a good time to tag a version, for the following reasons:

• we haven't tagged a version since April 2017
• the current spec text describes, to the best of our knowledge, what NSS and pod-server implement.
• NSS is now basically in feature-freeze wrt spec changes, so it's good to have a spec version number to refer to.
• there are a lot of new proposed spec changes coming up, so we could say they should all get discussed in parallel and then lead to one big spec update from 0.8 to 1.0, hopefully somewhere around Christmas.
• pod-server will implement the 0.8 spec for the coming six months, then switch from 0.8 to 1.0 in January 2020.

[michielbdejong]

Depends on:

• Various Documentation improvements webid-oidc-spec#27: PoP tokens were added to web-access-control
• Clarify and detail the definition of globbing to only apply to folders #148: Globbing clarified
• Removed references to TLS that imply it is the primary form of authenication webid-oidc-spec#26, Removed references to TLS as primary auth method #171: Status of webid-tls as auth method clarified
• Mention willful violation of the sparql-update spec #193: Willful violation of sparql-update clarified

[kjetilk]

Indeed, it sounds like a good time to me, but we need to allow time for people to chime in.

[RubenVerborgh]

Given "depends on", should we wait until those are merged before merging in this one?

Just want to repeat that there is no inrupt consensus on

pod-server will implement the 0.8 spec for the coming six months

We should not waste time on implementing mistakes that happened to end up in the 0.8 draft.
v0.7 and v0.8 are non-authoritative.

If you insist on implementing globbing and (the currently underspec'ed and thus non-implementable) SPARQL per-resource querying, we probably need additional champions within inrupt.

[michielbdejong]

Regarding what does and does not get implemented in pod-server and who champions what, please talk to @acoburn from now on.

Given "depends on", should we wait until those are merged before merging in this one?

Yeah, probably. Maybe we can ask @Mitzi-Laszlo to try to shepherd that process if it takes too long?