# 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)