Viewgraph · 6 frames
The resolution sequence
The logical steps a conforming resolver follows, the eight typed outcomes, and how Document 08 v1.1 maps them to HTTP without leaking what policy keeps private.
Viewgraph6 frames
Resolution
Verify first, then disclose
Resolution maps a persistent identity to current, permitted information. It is not fetching a file.
RSM ID Learning Center
rsmid.org
Input
Every input becomes a canonical RID first
Names go through the versioned names API, never as a path segment; only the approved host's HTTPS form is trusted.
Rendering diagram…
Syntax is checked before anything else: malformed input ends as invalid.
Logical steps
Seven steps, in order
The prefix never names a server; trust and policy come before any representation.
Rendering diagram…
Trust failure ends as untrusted; a registry or space outage as unavailable.
Typed outcomes
Eight logical statuses, each with a default HTTP code
Errors should use problem+json with a stable code; deprecated and reserved are lifecycle states, not statuses.
A negotiated response; superseded carries successor information.
Malformed input, or no discoverable identity.
Each only where policy permits; otherwise an identical 404.
Trust cannot be established, or a retryable service failure.
Privacy
A restricted identity can look exactly like a missing one
Unless policy permits acknowledging it, the response is the same 404 — status, headers, and body.
Rendering diagram…
Headers, timing, redirects, and caches must not reveal the difference either, where reasonably controllable.
On the wire
One identity, several representations
The proposed gateway reserves GET and HEAD on each RID path; once resolution is enabled, the documentation site must not shadow them.
text/html, application/json, or application/ld+json; nothing acceptable is 406.
Same status and headers, no body; Vary: Accept when negotiation applies.
Public responses need explicit freshness; private ones use private, no-store.
Read as text
- ResolutionVerify first, then discloseResolution maps a persistent identity to current, permitted information. It is not fetching a file.Source: Document 08 v1.1 §6.1, §6.3
- InputEvery input becomes a canonical RID firstNames go through the versioned names API, never as a path segment; only the approved host's HTTPS form is trusted.A canonical RID is used directly. A registered RRN or RSN is mapped to its RID through the names API. An HTTPS identifier on the approved host yields the RID in its path. All three arrive at one canonical RID.Source: Document 08 v1.1 §6.2, §18.5
- Logical stepsSeven steps, in orderThe prefix never names a server; trust and policy come before any representation.The resolver validates RID syntax, verifies the registered prefix, locates the identity record, verifies authority, evaluates lifecycle and disclosure, selects a representation, and returns a result or a typed status.Source: Document 08 v1.1 §6.3; Document 09 v1.1 §7.4
- Typed outcomesEight logical statuses, each with a default HTTP codeErrors should use problem+json with a stable code; deprecated and reserved are lifecycle states, not statuses.resolved 200 · superseded 200A negotiated response; superseded carries successor information.invalid 400 · not_found 404Malformed input, or no discoverable identity.forbidden 403 · retired 410Each only where policy permits; otherwise an identical 404.untrusted 502 · unavailable 503Trust cannot be established, or a retryable service failure.Source: Document 08 v1.1 §6.8, §18.6, §18.7
- PrivacyA restricted identity can look exactly like a missing oneUnless policy permits acknowledging it, the response is the same 404 — status, headers, and body.Internally, a restricted identity is forbidden and an unknown one is not found. When policy does not permit acknowledging the restricted identity, both leave the gateway as the same 404 response.Source: Document 08 v1.1 §18.7; Document 09 v1.1 §15.3
- On the wireOne identity, several representationsThe proposed gateway reserves GET and HEAD on each RID path; once resolution is enabled, the documentation site must not shadow them.Accept negotiationtext/html, application/json, or application/ld+json; nothing acceptable is 406.HEAD matches GETSame status and headers, no body; Vary: Accept when negotiation applies.CachingPublic responses need explicit freshness; private ones use private, no-store.Source: Document 08 v1.1 §18.5, §18.8 — rsmid.org is a proposed host, not an operational resolver
Sources and provenance
Normative basis
- Document 08 v1.1 — Section 6.2Resolution input
- Document 08 v1.1 — Section 6.3Logical resolution sequence
- Document 08 v1.1 — Section 6.8Resolution statuses
- Document 08 v1.1 — Section 18.5Resolution input and HTTP routing
- Document 08 v1.1 — Section 18.6Resolution response and representation distinction
- Document 08 v1.1 — Section 18.7Logical status to HTTP mapping
- Document 08 v1.1 — Section 18.8Federation, trust, caching, and failure handling
- Document 09 v1.1 — Section 7.4Resolver sequence
- Document 09 v1.1 — Section 15.3HTTP implementation profile
This viewgraph is an informative explanation. Where it and the specifications differ, Documents 08 and 09 v1.1 govern.
What it contains
- Document 08 v1.1 · normative
- Grounded directly in Document 08, the controlling standard. Cited by section.
- Document 09 v1.1 · reference implementation
- Guidance from Document 09, the proposed reference implementation. Subordinate to Document 08; its technology choices are not requirements.
- Interpretation
- Explanation or design rationale written for this Learning Center. It does not add requirements.
- Proposed, not operational
- Something the specifications propose — a host, a prefix, a federation, a service — that does not exist yet.
Related
Pathway: Resolution · Technical · Revised 2026-10-09 · Content ID viewgraph.resolution-sequence (a page identifier on this site, not an RID)