Should a Solid server limit the reuse of URLs?

[acoburn]

In a non-normative section, the LDP specification states that LDP servers should not re-use URIs. Does the Solid specification take a stance on this, one way or the other? What if a client deletes a well-known URL, such as /profile/card or /public/inbox?

[RubenVerborgh]

I follow the text of the LDP spec there; the intention is that the same URI is never used to identify another resource. In practice, servers cannot know whether a resource that was deleted but then reinstated is the same or different.

Hence, I think this is non-enforceable.

[csarven]

It is not that it is impossible but that such setup requires additional machinery applied consistently over time. Certainly immutable snapshots of resources can exist and they can be used to compare if the server and the URI owner is willing. As one one would expect, having anything along those lines - more importantly the promise - is complicated for all parties involved.

Limiting URI reuse would not only require a higher bar for servers but for clients as well. It entails that clients will also need to know how to handle the failure ie. noting that a particular URI use differs from a previous issue.

I would suggest that the Solid spec should not set this as a requirement. The LDP covers at a good level in that it is non-normative and just throws in "LDP servers should not re-use URIs". That sounds like making a best practice suggestion to me.

I would also add that when we have more clarity on how immutable resources are used in Solid, that may help to phrase non-normative text about how it may be purposed to handle URI reuse, collisions, etc.

[RubenVerborgh]

Warning: pedantic comment ahead.

It is not that it is impossible but that such setup requires additional machinery applied consistently over time. Certainly immutable snapshots of resources can exist and they can be used to compare if the server and the URI owner is willing.

The only thing we can achieve with that is enforcing the same representation, but not the same resource. Hence, we do not enforce that the same URI is never reused with another resource.

A resource (in the REST sense) is a conceptual relationship, whereas a representation is a value of that resource at a given point in time.

Suppose I define the resource https://pod.example/weather/today as today's weather. Then I would update representations such that:

• Monday: sun
• Tuesday: rain
• Wednesday: sun

Now suppose that, after Wednesday, I get tired of maintaining the weather, so I DELETE it. But on Friday I change my mind and I want to put:

• Friday: snow

A system that remembers representations would not allow me to do that, because it is a different representation from the last one.

However, the resource definition never changed.

We can also find examples in the opposite direction.

---

The above should substantiate my point that enforcing non-reuse through representation comparison is impossible.

The only thing we can enforce is that, once DELETEd, one can never write again (so conceptually 410 instead of 404). However, that is undesirable for other reasons.

[csarven]

With the AWWW context, LDP is only referring to resources associated with a URI, so I don't think we need to drop to discussing URI reuse with different representations.

I think Solid's stance should be the same as LDP's and not say anything more. Beware and follow "best practice", but there is no testable criteria. If Guinan's profile gets deleted, it can come back as Guinan's profile (ideal and inline with AWWW), however, no prevention (in a testable sense) where it can also come back as Jean-Luc's profile or associated with today's weather (not good). It essentially falls back to whatever association the URI owner makes.

@acoburn Did I/we correctly interpret your question?

[acoburn]

@csarven yes, your interpretation of my question is in line with how I have been thinking about it. I am also 👍 on taking the same stance as LDP on this issue, which is to say that this issue could be considered out of scope for the Solid specification.

[csarven]

[
Slightly off tangent but a bit more about the practice in context of AWWW is mentioned at:

https://www.w3.org/TR/ldp/#ldpc-post-dontreuseuris :

5.2.3.11 LDP servers that allow member creation via POST SHOULD NOT re-use URIs.

https://www.w3.org/TR/ldp/#ldpc-put-create :

5.2.4.2 LDP servers that allow LDPR creation via PUT SHOULD NOT re-use URIs.

How that's done is unspecified of course. Whether the server keeps tracks of which URIs were previously created, deleted.. or relying on UUID strings in URIs or whatever is an implementation detail. There may be legitimate reasons to ignore though (re "SHOULD NOT").
]

[kjetilk]

Since this is now an issue for #145, I think we need to further this discussion.

My hunch is that we allow servers to decide upon certain behaviours for extra security, i.e. servers may do the following:

• Require acl:Control to delete a resource's ACL
• Set 410 once all representations of a resource have been deleted,
• and so prevent that identifier to be reused.

If a server does all these three things, the client is able to understand why they are not able to create a certain resource, they can understand that the identifier has been used before, by looking at the 410.

This causes some extra variability, but it could also be a security feature.

[csarven]

and so prevent that identifier to be reused.

Let's be careful with the nuance. The context of this issue and LDP/AWWW "reuse" is URI persistence: https://www.w3.org/TR/webarch/#URI-persistence

That is to say that a URI can be reinstated while maintaining the association it once had with a resource. It may potentially be an issue if the URI is reused for something else. That's what we want to generally avoid.

I think that "reuse" is orthogonal to the access control case on reinstating the resource for the purpose of changing its access control.

---

I suggest that the we address the issue at hand in two steps. The first is sufficient for this issue and the initial draft. I think this will also adequately address #90 , #121 .

First specify the general rule, and then specific cases - through other issues with use cases - with well-defined behaviour or supplemented with provenance data. Until we work out the details of the special cases, it may suffice to derive Solid's requirement from LDP 6.1.2 or simply refer to AWWW's recommendation:

Servers should not re-use URIs, regardless of the mechanism by which resources are created. Certain specific cases exist where URIs may be reinstated when it identifies the same resource, but only when consistent with Web architecture [URI persistence].

[ericprud]

I +'d @csarven's text but maybe solid users need more guidance (and the web architecture doc doesn't really provide it). I guess the "right" architecture is when you redirect ephemeral URLs to some persistent store, e.g. https://pod.example/weather/today 307s to https://pod.example/weather/2020-03-10 today and to 2020-03-11 tomrrow. In that case, weather/today is pretty much outside the Solid infrastructure and the dated URLs should never be changed to represent a different concept. Should we tell folks to DTRT? Should we provide them with a means to do so?

[kjetilk]

Yes, I think that in the first draft, it is sufficient to refer to AWWW's recommendation that server shouldn't reuse URIs.

Later, we can create a mechanism that allows server to add redirects or 410's, and so implement more restrictive policies, where ACL deletions may be enforced. I think we have to do that with fairly high priority, but probably not this spring.

[csarven]

weather/today is pretty much outside the Solid infrastructure

Wouldn't 307 persist the association made to the original resource? weather/today is intended to be about today's weather regardless of the redirect.

[ericprud]

I thought the point of a temporary redirect is that the client shouldn't persist it.

Though the real point is that I don't think we're offering any mechanism for users to control response codes and Locations and that doing so would require web server configuration directives and code that honored them.

[csarven]

The temporary redirect (to weather/2020-03-23) doesn't discard (or de-associate with "today's weather") the original request URI (weather/today), and the client is told to continue to use the original URI that's associated with the resource description ("today's weather"). As I understand it, when a URI owner uses 307, to some degree it ensures that the representation at the target URI and the original URI are sufficiently consistent. But of course if the target URI is controlled by a different authority, it can potentially differ.

We are not offering anything new with the redirects, but I also don't see how it can address the issue here regarding limiting URI re-use. On the other hand, I do find 410 as a blanket approach (non-normative) for servers to disable re-use ie. once a resource is deleted eg. WebID URI, it can't be reinstated (not necessarily indefinitely either). In cases like WebID URIs, some servers may allow reinstating if and only if the original association with the intended agent remains. In this case, it doesn't conflict with the URI re-use case any way. On that note, we don't specify how a server or a URI owner determines representation consistency (re AWWW's good practice).