Reconsider write rules for Auxiliary Resources

[CxRes]

Write rules for Auxiliary Resources fail to account for many scenarios:

Spec says:

When a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it LINK.

This should not happen in case of a server managed auxiliary resource such as the description resource which is managed by the server. For example, we do not want PUT requests to rewrite notifications metadata which is entirely server managed.

Further, there are restrictions for writing on containers.

Servers MUST NOT allow HTTP PUT or PATCH on a container to update its containment triples; if the server receives such a request, it MUST respond with a 409 status code. LINK

Servers MUST NOT allow HTTP POST, PUT and PATCH to update a container’s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code. LINK

These rules must also apply to the description resource of containers. In which case, they will contradict the rule on the top.

From a cursory reading of linked sources in the spec, it seems to me that rules for managing Auxiliary Resources have been thought of in terms of ACL files.

[csarven]

Server always has the right to reject requests if unable to process contained instructions, including cases in which constraints are not met, such as protected information in order for the URI owner to preserve the semantics of a given resource. Should that be clear in one or more specs?

[CxRes]

Yes, I think it needs to be made explicit. I can see that spec mentions this in 4.2.1, but asking implementors to solve "Do (this), But (look out for that execption)" from statements in different parts of the spec is not the way to go, as precedence of rules might not be clear. I would, for example, prefer (don't take the suggested language literally but as a WIP):

When a PUT or PATCH method request targets an auxiliary resource, the server MUST create or update it EXCEPT when the update modifies resource's metadata or other information that affect the semantics of a given resource.

Servers MUST NOT allow HTTP POST, PUT and PATCH on the container or any of its auxiliary resources to update a container’s resource metadata statements; if the server receives such a request, it MUST respond with a 409 status code.

[CxRes]

I am also wondering, and I have perhaps seen you discuss this somewhere: Should Solid spec also not specify that this information be provided to the client using a constrainedBy link header as required by LDP spec section 4.2.1.6.

[csarven]

https://solidproject.org/TR/protocol#constraints-problem-details

[CxRes]

4.2.1.6 in the LDP Spec is a MUST. 5.6 in Solid Spec talks about encouragement in a normative section, which is a euphemism for "it can be done, but you really need not bother."

If Solid wants to be consistent with LDP specification wrt constraintby, then it should reside in a normative section with a MUST and ideally linking to the LDP spec.

As a general note, specs are the place to firmly constrain implementers from the get go, rather than negotiating with them, especially near or after a v1.0 release.

[csarven]

Yes, it is "encouraged" for the time being for all the reasons I've outlined in #185 . Is there sufficient data making the case either way for Solid servers? How about what applications are doing or want to do? Any signal?

Quite literally anything can be said in the spec but if it is not backed with adequate implementation experience, it will fall apart or short in the wild. That's quite a certainty (in my experience, and undoubtedly many others) despite whatever people want to pretend to tick a checkbox. Even a "Recommendation" is not going to prove anything. Case in point: let's see the data for how well LDP servers/clients are making use of ldp:constrainedBy.

I have been a strong proponent of having this possibility exposed by Solid servers so that we/I can have (my) application take advantage of stuff. As I've said elsewhere (in specifications, and some implementation repositories), features like this need to go along with referencing specific requirements (some implementations at least adopted that in their documentation at least); have structured errors; link to expected shape; and so forth.

Just making this a normative / MUST in the specification does nothing concretely or reflects reality. Clearly the Solid Protocol doesn't need to be "consistent" with LDP on this point. If anything, the text in #constraints-problem-details as I see it tries to pave the way forward. And as mentioned in the PR following this, we can indeed make it a requirement.

As for your other suggestion on making the text more clear so that the reader has a better way to associate / navigate to related content, I agree, and happy to do so / look into it.