so what do we mean when we say ids are opaque and you shouldn't extract information from them? well, you have to be careful about not extracting information that isn't actually there.
typically the warning is supposed to stop you from doing things like assuming paths such as /api or /users/username -- because not everyone is going to assign the same resource names in the same ways.
we might infer every resource name starting with /~a/ is owned by me, because that's "my user folder". maybe not
so what do we mean when we say ids are opaque and you shouldn't extract information from them? well, you have to be careful about not extracting information that isn't actually there.
typically the warning is supposed to stop you from doing things like assuming paths such as /api or /users/username -- because not everyone is going to assign the same resource names in the same ways.
we might infer every resource name starting with /~a/ is owned by me, because that's "my user folder". maybe not
@trwnh No, no, IDs are opaque, if you're in the https scheme, you're not talking about IDs, you're talking about locators.
This is the whole locators can be used as identifiers, but not vice versa thing.
So if you DO use locators as identifiers, you're right that you SHOULD not extract facts from them, even though you could.
@trwnh Technically that's wrong, of course, but it's the easiest rule of thumb if you don't want to also dive into the whole URN mess.
https://www.rfc-editor.org/rfc/rfc3986#section-1.1.3 has details.
Also https://www.rfc-editor.org/rfc/rfc3305#section-2 is worth a read.
The TL;DR is that this "classical view" always assumed we'd get to a point where we would use URNs to identify resources, and have a resolution service kind of like DNS resolve those to URLs.
The "contemporary view" is just giving up on that.
Nonetheless, the upshot is...
@trwnh ... that the scheme is the first instance the only fact you can extract from a URI.
Everything following the separator is up to the scheme. The did scheme just uses colon, because that's effectively inherited from URNs.
So you can do whatever in your scheme, really.
@jens HTTP Semantics (9110) and URI Design And Ownership (8820) describe some considerations for http: and https: identifiers but outside of a pure identity function (exact match these bits to these bits) there's a more metaphysical question about how "ownership" or "trust" work when dns is built on so many delegations. with ostatus dot org being a zombie site now for example, we still use authorize-interaction link rel. but say it was a legit reregistration; what happens
@jens to what extent is a registrant responsible for identifiers minted by a previous registrant? that's more what i'm trying to get at
/ is in theory a subresource delegator/separator, but this isn't actually defined in http semantics (which https: uses). in https: you are mostly talking to the host, which might relay messages internally to resources, but generally the host server communicates on behalf of the hosted resources.
so we can't say /~a/bio.html is my bio. it could be anything. the host gets to route messages according to its own configuration for which resources are backed by which interfaces.
but there is still something there that hasn't been captured. some inferred facts that you might use in a trust model. who "owns" (or rather "controls") foo.example/~a/bio.html really?
it's actually a cascade of authority!
- i have my subdirectory with write perms
- but i am hosted by the server running on foo.example
- but that depends on the dns records
- and that depends on the registrar which sets authoritative dns nameservers
- and that is rooted in the IANA!
so do we say IANA owns all?
what IANA does is *delegate* to the tld, then the registrar, then the registrant, then the authoritative nameserver, then the dns record, then the server admin, and finally me.
so do all of those "control" foo.example/~a/bio.html then? in a way, yes! but how do we do anything useful with that information? how do we model trust with so many entities involved?
this is usually where you might use what can be called a "container". a container is a sort of bounded context that "contains" items. the container is also a resource that manages its internal subresources.
for simplicity we can say https://foo.example/~a/ is a Container, then say things like "it is controlled by me" or more precisely "i have write access to the container". we can say "it contains bio.html".
now here's the crucial part: can we or can we not infer anything from a resource's uri, given we know some uri prefix is a container?
strictly speaking, no. containers can contain items with different prefixes.
but *practically* speaking we do something similar all the time with https: and the "origin" model! we assume /~a/bio.html is a subresource of foo.example because we are talking to foo.example (via http over tls).
