Fieldnote
Why resolution is not simply fetching a document
An identifier names a resource; a URL locates a file
Most identifiers people meet on the web are locations: follow the link and a file arrives. It is natural to expect an RSM identifier to behave the same way — a slightly more permanent link. Document 08 starts its resolution chapter by refusing that picture, and the refusal shapes everything that follows.
Each word in that list breaks the file model. A watershed is physical; there is no file to fetch. A concept is abstract. A restricted research note exists but may not be shown. A retired resource may have nothing left but a tombstone. And a single resource may have an HTML landing page, a JSON identity response, and a JSON-LD description, none of which is the resource. A resolver therefore has to decide what is true and permitted before it can decide what to send.
What a resolver does instead
Only one of those seven steps resembles fetching. The rest establish trust and permission: is this a registered namespace; is the source that claims the record really authoritative; is the identity active, superseded, or retired; may this requester learn that it exists at all? The outcome is typed, so a client can tell retired from unavailable from untrusted — distinctions a 404 for a missing file cannot carry.
Landing pages and redirects
Document 08 prefers that the persistent identity URL yield a durable identity landing page rather than always redirecting to a transient application route. The reason is the file model's weakest point: when content moves or is withdrawn, a redirect-only identifier breaks or points somewhere wrong. A landing page keeps discoverability and provenance in place — and, crucially, it describes the resource without claiming to be it. Redirects remain available under an explicit mode or suitable negotiation, where policy allows.
On the wire
A request for GET /451.7K4M9Q2X8D5P0R6T with Accept: application/json would return 200 and an identity response with at least rid, kind, identityStatus, and resolutionStatus. The same request for the retired line 451.4713F4VRP8NYZ2D3 would return 410 with a tombstone where its publication is permitted, otherwise 404. A request for a restricted note whose existence may not be acknowledged returns the same 404 a nonexistent identity would, with no difference in body or headers where reasonably controllable. None of these is the outcome of fetching a file; each is a decision. The resolver demonstration shows these exchanges, labelled as simulated.
The tradeoff is real: resolution is slower and more complex than following a link, and it needs registries, trust bindings, and policy that a plain URL does not. What it buys is an identifier that stays meaningful when files move, owners change, access narrows, or the resource itself is gone. The resolution sequence draws every step.
What remains open
Document 08 v1.1 fixes most of this behaviour, but not all of it. It does not yet say which typed status an unregistered prefix should produce, the bodies of the names-lookup API are unspecified, and the deprecation notice and "limited permitted record" for a reserved identity have no defined format. The site's resolver demonstration labels each of those choices as its own reading. Above all, a simulation is not conformance: Document 08 says plainly that a public educational simulation does not count as proof that a production resolver conforms.