---
# System prepended metadata

title: Solid Editorial Session - Specification Features

---

# Solid Editorial Session - Specification Features

Date: 2021-04-22

## Minutes

JB: Goal for this session?

TBL: Ensure functionality at each level is well understood and specified. The spreadsheet should provide clear history of features and what's available in past versions, current, coming soon.

JB: What's the scheme for versioning?

TBL: Important to make snapshots of the spec, and not have it be a totally living document. Don't have to do it very often, but it needs to happen at key times.

RV: How to avoid not becoming too messy? How do we deal with it from an implementer perspective? How to advertise what's implemented? What are consequences of indicating issues / risks with past versions.

TBL: Should be able to go to .well-known and get the version. 

RV: If servers advertise their version, it could help with understanding feature support levels, etc.

TBL: Client software could actually identify whether something is insecure.

RV: Need a versioning spec / process.

JB: +1 on server advertising version for interop.

JB: What is our version now?

TBL: Not using SemVer for pre-1.0

RV: Could even be date-based - to avoid version numbering

TBL: E.G. Solid 2020

RV: Benefits of Semver? E.G. Taking advantage of built-in semantics for programmatic scenarios

JB: Paper on RDF / SemVer - https://www.researchgate.net/publication/228716298_Semversion_A_versioning_system_for_RDF_and_ontologies

*[TB waves]*

JB:  with shapes you need best pracxtices about back compat with shapes.

TB: Propose in the

JB: Does the spreadsheet provide a good representative list at this point?

RV: High level yes - but needs some more detail. Especially with version estimates. Also should try to get expectation of when (for things that are changing / getting added). What is the minimum version that should be provided by a server to be minimum solid? What about versioning the whole ecosystem?

KK: Coming back up to speed - don't have full context - but need more about conditional requests and caching and that should be addressed.

TBL: Past solid we didn't use ETags

KK: Use RFC references and point to those

KK: Should we include VC?

JB: May not require server support for certain use cases (like signing / verifiable data)

TBL: Use cases for authn/authz probably will

TBL: Lots of things that aren't on here (i.e. Conneg) - maybe should do another round (at least offline)