Lacking specification of rules of HTTP methods for Description Resource

[renyuneyun]

Issue Content

I'm finding some use cases for the Description Resource (DR), but found that the way how they can be manipulated is not made clear in the spec. In particular, the following questions are unanswered (assuming permission is met):

0. (Prerequisite of the rest) Is the user allowed to modify the DR?
1. What HTTP requests are supported for a DR?
   • I presume OPTIONS, GET, POST, PUT and PATCH are all supported in the same way as a normal resource when the DR exists?
2. Can I send a DELETE request to the DR, and what would happen?
3. If, for some reason, there is no DR for a resource yet (but server has capacity), how can I create a DR?
4. Am I allowed to associate a different DR with the resource on a custom location?

Also, this sentence is not clear enough:

Servers MUST NOT directly associate more than one description resource to a subject resource.

Does this mean the server can indirectly associate more than one DR to a subject resource? If so, how?
Or, does this mean the user (rather than the server) can associate more than one DR?

Generalization

Actually, this question can be generalized to all Auxiliary Resources (AR): what ARs can be modified by the users, and are they subject to the same mechanism?

Related topics

• Reconsider write rules for Auxiliary Resources #521: It concerns all types of AR, especially ACL; it assumes DR are managed by server (thus not modifiable by user); it also does not discuss modifications.
• Restrict linking and creation of extended auxiliary resources #184: It concerns all types of AR as well, in terms of recursive AR (i.e. AR of AR); it also touched a bit on the ACL and use cases of recursive AR.
• Auxiliary resource for container metadata as alternative #362: It discusses the possibility to use DR to store container's metadata (managed by server?); it is more a use case for DR rather than protocol for interacting with DR.
• Clarify the notion and mechanisms for server-managed information #177: It talks about server-managed resources, and assumes all AR belong to this category. However, since ACL is modifiable by users, some differences must exist in AR.
• Maybe some other issues with label "topic: auxiliary resources", but I don't see any more for now

[csarven]

I write the following based on how the Solid Protocol currently works. It is sufficiently consistent to the best of my knowledge, and if there is some ambiguity, I can certainly try to clarify that further in the specification. That aside, as I've mentioned elsewhere, I will follow-up with a proposal that makes some (progressively enhanced / non-breaking) changes to how auxiliary resources work which I hope to be an improvement on the current.

(Prerequisite of the rest) Is the user allowed to modify the DR?

Yes.

What HTTP requests are supported for a DR?
I presume OPTIONS, GET, POST, PUT and PATCH are all supported in the same way as a normal resource when the DR exists?

Generally all of that including HEAD. However, realistically, whatever the server advertises in the Allow header field of any given DR. Note also that the processing of POST targeting a non-container resource is not defined by the specification, so while a server implementation may successfully accept the request, it is not expected to have the same (or any) behaviour as another implementation that accepts it as well.

Can I send a DELETE request to the DR, and what would happen?

There is a degree of variability here and that's important to retain. Fundamentally, the URI owner delegates the constraints for a given DR just as they do to any Subject Resource (SR) to a server. In absence of that, the server is expected to honour client's request to DELETE. That aside, servers are required to advertise (link relation) the DR of a SR, including for example the storage description resource ( https://solidproject.org/ED/protocol#server-storage-description ) which is essentially the DR of the Storage Resource). A DR could be DELETEd, and in a subsequent GET request to the same URI, for instance, the server may not generate a representation content, however clients having permission to update the DR can do so as usual. Since the server managed the link relation from the SR to DR, the URI of the DR can change. I emphasise again that how some of these details (e.g., same or different URI once DELETEd) pan out can be implementation dependent and it doesn't impact server-client-interoperability because clients are expected to discover the DR from the SR.

If, for some reason, there is no DR for a resource yet (but server has capacity), how can I create a DR?

There is no mechanism specified for clients to associate a DR to a SR. The server manages this association ( https://solidproject.org/ED/protocol#server-auxiliary-resources-management )

Am I allowed to associate a different DR with the resource on a custom location?

You as the user with an application, no. You as the URI owner in an unspecified way, yes. This goes for anything, as the URI owner, you decide what URI may be allocated to a resource and what its semantics may be, how they're self-described, and so forth, and that arrangement depends on the server you choose to use and what configuration possibilities it offers.

Does this mean the server can indirectly associate more than one DR to a subject resource? If so, how?
Or, does this mean the user (rather than the server) can associate more than one DR?

Directly being the link relation requirement. I'm not sure what "indirectly" would mean. The semantics of a particular DR is to a particular SR. So, while in theory a server can pretty much do whatever (TM), it is neither meaningful or intended to use the same DR for multiple SRs. Again, server manages the link relation (rather than the user).

[renyuneyun]

Thanks for the detailed explanation. Indeed it's worth clarifying.

That's sufficient for my use cases, and I'd be interested to wait and see what additional mechanism and additional use cases are there.

Shall I close this issue now, as it's answered, or close it after the spec is updated with (something that reflects) the above information?
(I may be able to help drafting a PR with necessary changes if that's easier.)