What does an append operation imply?

[kjetilk]

Appending to a resource is a central tenet of Solid, and I'm not sure we have issues open already to address it sufficiently, thus this issue. This is of relevance in discussing #108 . LDP doesn't discuss append, AFAICS, so we have to.

It is founded in the acl:Append access mode in the current WAC document, which states:

acl:Append gives a more limited ability to write to a resource -- Append-Only. This generally includes the HTTP verb POST, although some implementations may also extend this mode to cover non-overwriting PUTs, as well as the INSERT-only portion of SPARQL-based PATCHes. A typical example of Append mode usage would be a user's Inbox -- other agents can write (append) notifications to the inbox, but cannot alter or read existing ones.

For LDP-RS, it seems straightforward, as it eventually boils down to an RDF Merge, either through POST, non-overwriting PUT (seems awkward to define to me), or an SPARQL INSERT through PATCH.

For LDP-C, there are two interpretations, AFAICS: it could be argued that creating a resource in a container is an append operation on the container. So, we need to figure out whether acl:Append on a container is sufficient to create a new resource in a container, or if you need acl:Write to do it. There is a slight difference in wording in the definition of POST between RFC2616 and RFC7231 on this, the former says:

Extending a database through an append operation.

which could support the notion that creating a resource in a container is extending a database and so an append operation, but the latest RFC does not support that (at least to the same extent).

For LDP-NR, it seems quite a lot harder, since it depends on the media type whether it is possible to append to it. We could define some general rules around what you'd do if your media type does not support appending, or we could just be strict for now and say that LDP-NR cannot be appended to.

[csarven]

7231 just lists examples but ultimately what happens is "according to the resource's own specific semantics". So, POST to a LDPC resource (creating a new resource and adding containment triple is taken as a whole) is sufficient with acl:Append.

The spec doesn't need to prohibit appending LDP-NR. Allow that to evolve independently and we can revisit. I prefer the approach of specifying the append fail if media type is not supported for any kind of LDPR.

[kjetilk]

7231 just lists examples but ultimately what happens is "according to the resource's own specific semantics". So, POST to a LDPC resource (creating a new resource and adding containment triple is taken as a whole) is sufficient with acl:Append.

Yes, and it seems this interpretation is supported by the current NSS implementation, it allows the creation of a child resource with only acl:Append permission.

The spec doesn't need to prohibit appending LDP-NR. Allow that to evolve independently and we can revisit. I prefer the approach of specifying the append fail if media type is not supported for any kind of LDPR.

Yes, I am now convinced that is the correct approach.

[kjetilk]

So, perhaps something along these lines:

acl:Append is sufficient to alter the state of a RDF resource R if the resource can be altered

1. without reading it,
2. without changing any existing triples.
3. without side-effects changing the state of any other resource Q, except when acl:Append also applies to the resource Q.

acl:Append is implied by acl:Write.

Wouldn't that cover it? It should cover the creation of new resources, since that's basically altering the created resource, which is permitted, and using side-effects to bring containment triples into existence. It would allow RDF Merge operations, (including INSERT DATA, which is defined in terms of RDF Merge), since that doesn't change any existing triples, but disallow any DELETE. It would also disallow INSERT ... WHERE, since that requires a read operation in the WHERE clause.

[csarven]

We should take care to not introduce a new definition in this issue but okay that if it can help to articulate the notion. Clarifying the relationship between HTTP and WAC would be pragmatic as in https://www.w3.org/wiki/WebAccessControl#WAC_relation_to_HTTP_Verbs

Append is an update in that information can be added but not removed, and categorically excludes operations to "read" and "replace", as well as unintended exposure or side-effects within that.

An append operation affects a set resources atomically and recursively. For example:

• adding a new resource to a container entails: i) create resource, ii) add containment statement about the created resource, iii) create parent or ancestor containers, and their containment statements as necessary.

• updating an existing resource entails: "add information to [the end of] it".

With respect to HTTP verbs that are intended for writing, POST and PATCH can be used for the purpose of append however not PUT or DELETE. In the case of PATCH, acl:Append would not allow the WHERE clause (re "unintended exposure or side-effects").

[kjetilk]

Actually, I think that we should introduce an authoritative and clear definition of what Append entails, since there isn't a document that can function as a normative reference as of now. As the w3c wiki says, it was mostly moved to Solid in 2016, and it falls on us to come up with a normative statement around it.

As I see it, we are in agreement on the notions, as we agree that the append operation has to apply to all resources affected by an operation, but we yet have to come up with clearer normative language, which is a topic for a drafting phase.

[csarven]

Yes we are in agreement on the notion but I'm hesitant to introduce a normative definition that goes beyond the definitions and expectations of the mechanisms involved.

We can only really see append to the extend that the available tech allows us to see. Beyond that is just hypothetical land - not grounded on experience. It has the risk of being a conceptual or language exercise. I don't feel entirely comfortable about having a definition that we have to fit things under later on when we encounter scenarios that's not as clear cut.

Any way, this is a non-blocker right now and we can wrap up here - at least between us but others can always/should chime in. Let's hash out what exactly works and communicates well in drafting.

[kjetilk]

Yes we are in agreement on the notion but I'm hesitant to introduce a normative definition that goes beyond the definitions and expectations of the mechanisms involved.

Yeah, it wasn't my intention to go anywhere beyond expectations of the mechanisms involved, but currently, there are no normative definitions, and there needs to be one.

Anyway, with the notions sufficiently clear, I'll move to rough consensus.