Repository: https://github.com/solid/specification - Technical Reports: https://solidproject.org/TR/ - Code of Conduct: https://github.com/solid/specification#code-of-conduct
1 reply
acp:allows in Link headers. You are also using it in the ACP Document, where it makes sense to have it be related to a acp:AccessPolicy
If you have an existing application that was built against the Node Solid Server it is likely that changes will need to be made to the application in order to work with the Enterprise Solid Server. This is due to the latest changes in the spec not being reflected in the Node Solid Server. " - can you comment on that @csarven?
Michiel, I think Oz and Emmet can clarify the statements in the blogpost. My interpretation - take this as informal as it can be: the statements in the blogpost alludes to the current activities in the authorization-panel. See the post's link to https://docs.inrupt.com/developer-tools/javascript/client-libraries/tutorial/manage-acp/ for clarification, where it states "ACP is an alternative to Access Control Lists and is being proposed for inclusion in the Solid specifications." That is accurate in that there are a couple of initiatives running in parallel, and this is what I can formally summarise on the current state of the CG's activities:
The authorization-panel is currently/generally transitioning from the Use Cases that was proposed to coming up with (Non-)Functional Requirements. The Requirements will actually be what all proposed solutions need to address as normative spec text. There is also the UC survey to determine which UCs the Community Group is interested in seeing/using/developing for servers/applications so as to help determine and prioritise which UCs the authorization-panel should focus on. At the same time, ACP is a WIP proposal addressing some of the UCs in which are not deemed to be covered by WAC. The details pertaining to delta/overlap between WAC and ACP are also being worked on. To make things even more interesting, there is the possibility of an Authorization Framework for the Solid Ecosystem which might tie up the work, allowing wider coverage of UCs by different (mostly/hopefully orthogonal) authorization systems.
So, it is all moving forward. Things should clear up in the next weeks/month(s?) As for the current Solid Ecosystem, WAC is currently a MUST for Authorization. The output of the authorization-panel will be proposed for the Ecosystem.
@aveltens:matrix.org
The spec says that if there is /public , /public/ can't be created. And, vice-versa. It also says that servers may want to redirect when requesting the non-existing resource (eg. /public ) to the existing one (eg. /public/ ). Now, only after that, it would be possible for client to receive the representation of /public/index.html if the client for example requested Content-Type: text/html for /public/ (after the redirect) , and if server uses Content-Location: index.html in response to /public/ . That's of course this particular server stores the HTML representation of /public/ at /public/index.html and wired up to be served through Content-Location.
Above is certainly possible and would still conform to the spec or at least there are no conflicts. It is not necessarily how every server might behave. Simple case being that server just won't redirect from /public to /public/ to begin with or associate /public/index.html as the HTML representation for /public/ .
If /public/index.html is an HTML representation of /public/ then all write requests targeting /public/index.html must be redirected to /public/ - the spec doesn't allow representations to be updated directly / separately. Updates are routed through the resource URL as opposed to representation URLs.
@timbl We could change "MAY" into non-normative may or just remain silent about it. Redirecting /public to /public/ is a fairly common implementation pattern. Redirect helps people to not trip over slash or no slash diffs or refer to one when the other exists.
Text from the specification:
If two URIs differ only in the trailing slash, and the server has associated a resource with one of them, then the other URI MUST NOT correspond to another resource. Instead, the server MAY respond to requests for the latter URI with a 301 redirect to the former.