Reconsider write rules for Auxiliary Resources

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.

Start by reading the linked auxiliary-resource and container-protection sections of the Solid protocol specification, then compare their rules for server-managed description resources. Resolve the contradiction and update the relevant specification wording so the allowed and rejected requests are unambiguous.