Why is Write on C enough for PUT C/R?

[RubenVerborgh]

From #14 (comment), we extract:

POST C/
Slug: R

C/	C/R	C/R exists	C/R doesn't exist
Append	-	201	201

PUT C/R

C/	C/R	C/R exists	C/R doesn't exist
-	Write	200	403
Append	-	403	403
Write	-	200	201
Append	Write	200	201

We ran into these questions while working on CommunitySolidServer/CommunitySolidServer#1161:

• Are POST and PUT inconsistent regarding Append? Why is Append on C not enough to create C/R?
• Why is Write on C enough to create or replace C/R?

[csarven]

Are POST and PUT inconsistent regarding Append? Why is Append on C not enough to create C/R?

PUT C/R entails a create or replace operation where the client requests the identifier that it wants allocate to a resource. This is a write-level requirement, and append-only on C/ is not sufficient to create or replace C/R. Whereas POST C/ entails an add (append/grow..) operation where the client requests to have the server allocate the identifier for C/R.

Why is Write on C enough to create or replace C/R?

Note this important bit from the table comment in issue 14:

All C/'s (containers) apply an access mode that can be inherited by C/R. Access mode marked with - indicates no access mode is explicitly set on resource.

So, the row actually reads: Write on C/ and Write on C/R.

---

Above is partly derived from and deemed to be consistent with RFC 7231, hierarchical containment, WAC, and implementations (in addition to consensus in issues/discussions). It is also partly captured in https://solidproject.org/ED/protocol#resource-type-heuristics and https://solidproject.org/ED/protocol#uri-allocation (in between the lines until perhaps more of the information from the table in issue 14 makes it into the spec or changes the spec.)

On a related note, in #160 (comment) I presented the rationale for the functional requirements and conformance rules for eg. POST, PUT and URI allocation.