Is create an append operation?

[michielbdejong]

Suppose c/ exists, and c/r does not yet.
An agent creates c/r. Does this require:

• Option 1: Append or Write on c/ and Write on c/r
  or
• Option 2: Append or Write on c/ and Append or Write on c/r

Evidence of option 1:

• this seems to be what CSS implements for PUT
• this is what the WAC tests were testing until recently

Evidence of option 2:

• this seems to be what CSS implements for PATCH
• it seems pretty clear that the spec says:

write operations attempt to create, delete, or modify resources;
append operations attempt to create resources or add information to existing resources

I want to go for option 2 (and update the WAC tests accordingly and file a bug report to CSS), but wanted to check here first.

[michielbdejong]

As Martynas mentioned on Gitter, probably option 2.
Let's wait a bit to give others a chance to comment in case there are more perspectives on this.

[michielbdejong]

CC @ylebre @bourgeoa @gibsonf1

[csarven]

The evaluation of an authorization is concerned with finding Authorizations that match the required parameters of an operation. It depends on the HTTP request semantics and conditions. See also https://solid.github.io/web-access-control-spec/#http-method-access-mode-mapping , #85 (comment) .

For example, /C/R would be created given: request PATCH /C/R or PUT /C/R and finding Append (or Write) on /C/ and Write on /C/R; request POST /C/ and finding Append on /C/.

[michielbdejong]

Ah, interesting. So then why does it say "append operations attempt to create resources or add information to existing resources"? Does that term "append operations" not refer to "operations for which acl:Append suffices"?

[michielbdejong]

@csarven so it's option 1 then, despite that phrase about "append operations attempt to create ..."?

[csarven]

It is hard for me to answer your question directly because the primary source (HTTP method) of the request semantics that indicates the purpose of the request and the target of the HTTP request (URI) in the scenario is missing. The complete HTTP request semantics needs to be taken into account in order to determine the parameters of an operation and what Authorization rule(s) needs to be matched.

Even without that information, it is still unclear whether the server or the client assigns the name C/R.

What you are quoting is a general description about operations. (But don't run off with that.) We can append to C/ with POST (it is a resource-specific processing resulting in C/R). We can also append or add data to an existing resource C/R (POST, PATCH) but this is not the scenario you're describing.

What I'm saying is that if an agent created C/R, it was probably because there was a PUT or a PATCH targeting C/R or a POST targeting C/.

Append suffices for POST targeting the C/ and that server will name C/R. Append on C/R will not suffice for PUT or PATCH - write is required so that client can name C/R.

If you're satisfied with the answer, feel free to close the issue.

[michielbdejong]

Yes, sorry, I forgot to state that I was talking about PUT and PATCH. OK, so option 1 then, thanks! I'll create a PR to edit the confusing text.

[michielbdejong]

As commented in #106, let's leave the spec text as it is but at least we have clarity now.

Thanks!