csarven on trust-between-owners-same-origin-multiple-storages
Trust between owners on same or… (compare)
as for protecting the resources in those locations, that would be entirely an implementation decision. One could also argue that users should be in control of their own data, and if they want to delete a container called /inbox/, they should be able to do that
agree - this isn’t something for the core protocol to determine, but a matter of user choice.
@/all What does everyone think about only using quoted access modes for the
WAC-Allow header? The current ABNF for WAC-Allow makes the quotes optional eg.
user=read are both valid. This was intentional. However, as brought up by @edwardsph in testing, if we take the ABNF as is, a parser that's following the ABNF as gospel could potentially generate unmatching quotes, and so it is not fun for clients to bother with something like
user="read public="" . This would be silly and in most situations it would probably be considered a bug by implementations.. but it might be better to tighten this up... so to simplify client's parsing.
Aside: when I originally wrote the ABNF, I followed Content-Type's lead ie. allowing both quoted and unquoted values. However, those don't say anything about unmatching cases.. or factored in.
ABNF is supposed to be "aspirational".. so, we have a couple of choices. We can do one of the following (relatively complex to simple order):
I think 2 or 3 will be fine. Slight preference for 2. 1 is overkill... and may still need some handholding with supporting text.
WOW, I guess I don't remember anything... since we already had this text:
The quoted and unquoted values for <code>access-modes</code> are equivalent. Servers are recommended to use quoted values in the response. Clients' are recommended to be able to parse both quoted and unquoted values.
Solid has the notion of containers to represent a collection of linked resources to help with resource discovery and
Are there any reference in solid spec to the lifecycle management. Is it within the containement triples with dates or etags .... Is there a W3 spec ? NSS use dates.
@bourgeoa In that context, "lifecycle" is as described in https://www.w3.org/TR/ldp/#dfn-containment . Happy to clarify this in the Protocol spec though. The intention is that a container gets to be aware of what happens to its resources eg. deleting a resource also entails that there is a cleanup task in which the containment statement is removed from the delete resource's container. There is also related requirements like disallowing a request to delete a non-empty container.
I'm curious to know what hinted at dates/etags for you though..
@csarven there where 2 questions : the first one came from solidos meeting where @timbl stated that in containement triples there should be date creation and date modified. I did not find any reference in solid spec. And the second was around the discussion in app-development chat around how to know that a resource has changed and where the first response was to check the body content.
If I may suggest that the solid specification give not only a global reference link but also to a paragraph link to the w3 specification.
Suggestion noted, thanks. I'm aware of the date info consideration about container resources in the container description.. will come back to this. (It is currently not a requirement).
For resource changes, yes, well, if authorized, and if present, Last-Modified or ETags are good indicators on each resource. To detect those changes from the container, yes, resource description (but again, if it is available.. and right now it is not required).
This is definitely something to clarify at the spec level, since different servers behave differently in this regard. Requiring child descriptions in the container listing, however, is problematic.
Consider a structure such as
</container/> ldp:contains <a>, <b>, <c> .
In order to view that data, an agent needs read access to
/container/, but may not necessarily have read access to a, b or c. Including descriptions of a, b and c in that container listing, however, will mean that the server will need to perform access checks on each of those child resources. In this simple case, that means 4 authZ checks.
Containers, however, can include an arbitrary number of child resources, and once that number grows, that means that every GET request to a large container could, potentially, be its own DoS attack.
One can achieve the same goals by using a query endpoint without the scalability issues