]> Link Genetic GmbH

Leugrueb 21 Zumikon 8126 Switzerland christian.nyffenegger@linkgenetic.com https://www.linkgenetic.com

Applications and Real-Time URI scheme persistent identifier resolution UUID This document specifies the "linkid" URI scheme and a resolution model for persistent, location-independent identifiers. A LinkID consists of the scheme name followed by a UUID and identifies a resource independently of its current network location. Resolution maps the LinkID to a current actionable URI using one or more resolvers. Resource names, locations, versions and operator relationships are associated data, not part of the identifier. The document defines syntax, comparison, resolution semantics and an HTTPS binding, and requests an update of the existing IANA URI scheme registration. About This Document This is an individual submission. Discussion takes place on the DISPATCH mailing list (dispatch@ietf.org). Source and issue tracking: .

Introduction Hyperlinks commonly couple resource identity to a current network location. When domains, paths, repositories, content-management systems or hosting infrastructure change, references fail even though the referenced resource may still exist. LinkID separates persistent identity from mutable location. The core invariant is: identity is persistent, location is mutable, and resolution is the controlled mapping between the two. Persistence is not a purely technical property. HTTP(S) URIs can be highly persistent when managed responsibly, and any persistent identifier system can fail if the organization behind it disappears. This document therefore does not claim that indirection alone guarantees persistence. It aims to ensure that a LinkID and its authorized mapping survive changes of custody and hosting, by separating identifier syntax from resolver operation. LinkID does not replace HTTP(S) or existing persistent identifier systems; see .

Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here.

LinkID:

A persistent identifier expressed using the "linkid" URI scheme.

Identifier authority:

The party authorized to maintain a LinkID's mapping and associated records. Authority is established independently of the UUID text; it is not encoded in the identifier.

Resolver:

A service or software component that maps a LinkID to a resolution result.

Resolution result:

The authorized current mapping and lifecycle status for a LinkID returned by a resolver ().

Actionable URI:

A URI in a resolution result that a client can use to access or interact with the identified resource.

URI Scheme Syntax The syntax is specified using ABNF ; HEXDIG is imported from that specification. The UUID text representation is defined by . A LinkID URI has no authority, namespace, path, query or fragment component. Whitespace, percent-encoded characters, braces and suffixes are not permitted. The scheme name is case-insensitive , and UUID hexadecimal text is case-insensitive . Producers MUST emit the complete URI in lowercase. Consumers MUST accept either case. Two LinkIDs are equivalent if and only if their UUID values are equal. Lowercasing a conforming LinkID yields its canonical form. Canonicalization MUST NOT turn a non-conforming string into a LinkID by discarding characters. Matching the grammar does not establish that the UUID was allocated, that a resource exists, or who controls it.

Opacity The UUID is opaque. Clients MUST NOT infer a resource type, name, location, owner or resolver from it.

Example An associated target could be https://example.org/handbook/2026/section-3; after an authorized migration, https://example.org/manual/section-3. The LinkID remains unchanged. Independently identified resources, such as a document, a passage of it, or an image, each have their own UUID. Names are metadata, not identifier suffixes. Query parameters or fragments needed by a target belong to the target URI.

Identifier Semantics A LinkID identifies a resource; it does not encode the resource's network location. Once assigned, a LinkID MUST NOT be reassigned to an unrelated resource. The actionable URI associated with a LinkID MAY change without changing the LinkID. One LinkID has one persistent identity. Multiple target addresses, historical addresses, language or format variants, and authorized fallback addresses can be associated with it without creating alternative identifier forms. Changing an address or transferring stewardship does not create a new identity; a resource version that is identified separately receives its own UUID. A resolver MUST NOT select an unrelated resource merely because it is reachable. Automatic recovery does not override the authority governing the original mapping. Successful resolution establishes the currently authorized mapping. It does not establish that destination content is safe, correct, trustworthy or unchanged.

Resolution Model A client resolves a LinkID by validating it against , selecting a resolver, requesting the resolution result, validating that result, applying local policy, and returning or navigating to the actionable URI. A LinkID MUST NOT depend semantically on a single resolver operator: the meaning of a LinkID does not change when the resolver that serves it changes.

Resolver Selection Clients use trusted resolvers designated by local, enterprise or application configuration. The UUID does not indicate an operator or resolver. Implementations MAY ship with default resolvers but MUST allow users or administrators to configure alternatives. A change of resolver MUST NOT change an assigned UUID or authorize a new mapping. Use of an alternative resolver does not prove that it holds an authoritative record for a LinkID. Interoperable discovery of the authoritative resolver for a given LinkID is not defined in this revision; see .

Resolution Result A resolution result conveys at least the LinkID, its lifecycle status () and, where applicable, the actionable URI. A client MUST verify that the returned identifier matches the requested UUID before using a target. A client MUST NOT treat a mapping as active merely because a response was successful or a target is present; it MUST check the status and local policy before navigation. Unrecognized members MUST be ignored and MUST NOT grant authority.

HTTPS Binding A resolver exposes a resolution endpoint identified by a URI Template using the "https" scheme and containing the variable "identifier", for example: The client expands the template with the complete LinkID and issues an HTTP GET request with "Accept: application/json". On success the resolver returns 200 (OK) and a JSON object with the following members:

id (string, REQUIRED):

The canonical LinkID.

status (string, REQUIRED):

The lifecycle status. Values defined in SHOULD be used.

target_url (string or null, REQUIRED):

The actionable URI, or null if none is authorized.

Unsuccessful responses are JSON objects with an "error" member that names the reason. Resolvers SHOULD use the following status codes and error values: Error Responses

HTTP status	error	Condition
400	invalid_identifier	Input does not conform to .
403	policy_denied	policy-denied
404	not_found	unknown
404	no_target	Known LinkID without an authorized or reachable target (inactive)
410	gone	revoked or tombstoned
503	temporarily_unavailable	temporarily-unavailable

Resolvers MAY use more specific error values and other 4xx status codes. Clients MUST treat only 404 with "not_found" as the unknown condition; any other error for a known LinkID MUST NOT be interpreted as unknown and MUST NOT lead to navigation. Clients MUST NOT interpret an HTML page, a transport failure or an intermediary error as a resolution result. A server error is not evidence that a LinkID is unknown. Resolvers MAY offer separate interactive endpoints that redirect browsers to an actionable URI. LinkID resolution MUST NOT be defined solely as an HTTP redirect service, and an HTTPS resolver URI MUST NOT be treated as the LinkID itself. Public resolvers MUST use HTTPS with validation of the server identity. This does not imply that public lookup requires user authentication.

Resolution States Resolvers SHOULD distinguish the following conditions where applicable. Resolution States

State	Meaning	Navigation
active	Current mapping is valid.	Use an authorized target.
unknown	No record for the LinkID.	Do not guess a target.
inactive	Assigned, no current location.	None.
deprecated	Identity superseded.	Only an explicitly authorized mapping.
revoked	Withdrawn by the identifier authority.	None.
tombstoned	Resource no longer exists; identity preserved.	No replacement assumed.
temporarily-unavailable	Resolution currently not possible.	Do not infer unknown.
policy-denied	Refused by policy.	Do not bypass policy.
integrity-failure	Record failed validation.	Do not use the record.

An unknown LinkID MUST NOT be redirected to unrelated content. A revoked or tombstoned LinkID MUST NOT be reassigned.

Allocation and Governance New LinkIDs MUST use UUID version 4 as defined in , with the random bits generated by a cryptographically secure random source. Random generation allows allocation by independent parties without coordination. Implementations MUST NOT knowingly allocate an assigned UUID to an unrelated resource; a detected collision MUST NOT overwrite the existing identity. Previously assigned identifiers MUST NOT be renumbered to satisfy this rule. Registration agencies, enterprises and resolver operators can have separate responsibilities and allocation policies. These are administrative relationships associated with records, not subdivisions of the identifier. A transfer of stewardship or hosting MUST NOT change an assigned UUID. It requires authorization and preservation of mapping provenance; changing a resolver address alone does not transfer control. Where continuity cannot be established, resolution fails safely rather than granting an unrelated operator authority. A service interruption does not prove that the resource has ceased to exist. DOI, ARK, URN and Handle identifiers retain their own syntax and governance. An association with them is held in metadata or targets, not embedded in the LinkID. Accreditation of resolver operators, service levels and dispute resolution are outside the scope of this document.

Relationship to Existing Identifier Systems

URNs :

URNs provide persistent names within registered namespaces but do not define a general resolution mechanism. LinkID combines a persistent identifier with a defined resolution model.

Handle System and DOI :

DOIs resolve through the Handle System. LinkID does not replace DOI names or governance; a LinkID can be associated with a DOI-identified resource through its targets or metadata.

ARK :

ARKs encode a Name Assigning Authority Number and use organization-operated resolvers. A LinkID does not encode an assigning authority.

PURL :

PURLs are HTTP URIs redirected by a PURL server and bound to its domain. A LinkID is not bound to a resolver's domain.

Interoperability Considerations

Existing Uses of "LinkId" The string "LinkId" is used in existing specifications independently of this scheme. For example, defines a "LinkId" XML element that carries a document link, such as a UNC file path. Such uses are unrelated to the "linkid" URI scheme. A LinkID is recognized by the scheme component () and validated against . The string "LinkId" in any non-scheme position does not constitute a LinkID and MUST NOT be interpreted as one.

Contextual Recognition Because scheme names are case-insensitive, a field label followed by a value (for example "LinkId: 4711") can be mistaken for a linkid URI by a generic parser. Therefore:

• Implementations MUST NOT treat a string as a LinkID unless it appears in a context that expects a URI and conforms to .
• Implementations SHOULD NOT scan free text for LinkIDs without such a context.
• A string beginning with "linkid:" in any case that does not conform to MUST be rejected and MUST NOT be passed to a resolver.

Documentation and user interfaces SHOULD refer to "LinkID URIs" or "linkid: URIs".

Independent Implementations A conforming client needs a URI validator, resolver configuration, an HTTPS client and a JSON parser. A conforming resolver needs authorized records and the binding in . Neither requires a particular operator's hostname, SDK or software. Technical compatibility does not confer authority over existing LinkIDs.

Use Cases Use cases include Web and domain migration; long-lived documents (PDF, office formats) with embedded references; enterprise knowledge systems; government, legal and public-record references; scientific publications and datasets; archives and custody transfer; machine-to-machine references; and tombstoning of resources that no longer exist.

Caching and Failure Handling Resolution results MAY be cached according to HTTP caching . Cached results MUST NOT be treated as authoritative after their freshness lifetime. HTTP freshness is not an assertion about identifier lifetime or destination health. Clients and resolvers MUST detect and bound resolution and redirect loops. Failures MUST fail safely: a client MUST NOT guess a destination for an unknown LinkID.

Security Considerations LinkID resolution introduces an indirection layer. Unauthorized modification of a mapping redirects every reference using the affected LinkID. Interfaces for updating records MUST be strongly authenticated and access controlled, and changes SHOULD be auditable. Public resolvers MUST protect against resolver impersonation, mapping hijacking, open redirects, phishing, malicious destination schemes, denial of service, replay of stale records, identifier enumeration and resolution loops. Clients SHOULD restrict the schemes of actionable URIs they follow (for example to "https"). Resolvers that fetch or inspect destinations MUST defend against server-side request forgery, including requests to loopback, link-local, cloud metadata and internal addresses, and MUST account for redirects and DNS rebinding. Misconfigured or compromised resolver configuration can misdirect lookups even though the LinkID is unchanged. Discovering an endpoint or a public key does not establish authority over an identifier. High-assurance deployments SHOULD protect the integrity of resolution results cryptographically; a common format is an open issue ().

Privacy Considerations Resolution requests reveal interest in particular resources. Resolver operators SHOULD minimize collection and retention of personal data and SHOULD publish their logging and retention policies. Public resolution SHOULD NOT require user authentication unless required by the resource or applicable policy. A LinkID contains no credentials or resource names, but can become a correlatable reference when linked to personal information. Operators SHOULD NOT place secrets in public metadata or unnecessarily forward client information to targets.

IANA Considerations The "linkid" URI scheme is registered in the "Uniform Resource Identifier (URI) Schemes" registry with Provisional status. This document requests that IANA update the registration as follows, in accordance with . The syntax below narrows the previously registered syntax to the UUID form.

Scheme name:

linkid

Status:

Permanent

URI scheme syntax:

See .

URI scheme semantics:

See and .

Encoding considerations:

ASCII only; no percent-encoding within the identifier.

Applications/protocols:

Persistent identification and resolution of Web, document, archival, scientific, government, enterprise and machine-to-machine resources.

Interoperability considerations:

See .

Security considerations:

See .

Contact:

Christian Nyffenegger <christian.nyffenegger@linkgenetic.com>

Change controller:

IETF <iesg@ietf.org>

Reference:

This document

No other IANA action is requested.

References Normative References Informative References Work in Progress, Internet-Draft, draft-kunze-ark ISO Internet Archive Microsoft Corporation

Implementation Status This section records the status of known implementations at the time of posting, following . The description is provided for the information of reviewers; inclusion does not imply endorsement by the IETF.

Organization:

Link Genetic GmbH

Implementation:

LinkID platform and public resolver (proprietary); client SDKs and this specification at

Licensing:

Platform and resolver: proprietary. SDKs: see the repository.

Contact:

christian.nyffenegger@linkgenetic.com

Coverage and maturity:

• Allocation: all identifier-creating paths, including DOI rescue and test data generation, generate UUID version 4 identifiers from a cryptographically secure source. Records allocated before this revision, including some with non-UUID identifiers, are retained and remain resolvable without renumbering.
• Resolution: a public JSON endpoint, /api/public/resolve/{identifier}, returns the members id (always in canonical form), status and target_url as defined in , and 400 invalid_identifier and 404 not_found. It additionally uses more specific errors: 403 region_blocked, 404 no_target and no_reachable_target, 410 for erased, expired, archived and inactive records, and 451 for suspended records. It returns further implementation-specific members (scheme, uuid, last_verified_at, registration_agency, version) and accepts legacy "lid:" input for compatibility. Separate browser routes redirect to targets.
• Multiple targets: the data model supports multiple, historical, language-specific and fallback targets per LinkID. A consistent target-selection algorithm across endpoints is not yet defined.
• Discovery and integrity: implementation-specific resolver descriptors and a signed record format exist under /.well-known/ paths. They are not registered under and are not part of this specification.
• Federation: independently operated, interoperating resolvers have not yet been demonstrated.

Open Issues The author seeks community input on:

1. Interoperable discovery of the authoritative resolver for a LinkID, given that the UUID carries no authority information (for example: configuration only, operator descriptors, a shared directory, or replication).
2. A signature format for resolution results and how clients establish trust in identifier-authority keys.
3. Which multi-target and lifecycle information should be exposed in an interoperable response, and how target selection (language, format, priority, fallback) should be described.
4. Representation of stewardship transfer and lifecycle history.
5. Transition handling for identifiers allocated under the broader syntax of the existing provisional registration and revision -00.
6. Which governance and operational aspects belong in an IETF specification and which in a separate operational framework.

Changes since -00

• Narrowed the syntax to "linkid:" followed by a UUID; removed non-UUID examples.
• Required UUID version 4 for new allocations, without renumbering existing identifiers.
• Separated identity from names, targets, versions, fallbacks and operator relationships.
• Defined resolver selection, the resolution result and an HTTPS binding aligned with the existing implementation.
• Added allocation, stewardship transfer and continuity rules.
• Added relationship to URN, Handle/DOI, ARK and PURL.
• Added interoperability considerations on existing uses of "LinkId" and contextual recognition (URI review feedback).
• Changed the change controller to the IETF.
• Added Implementation Status and Open Issues appendices; updated contact address and references.

Acknowledgments The author thanks Ted Hardie for the URI review, and the participants in the uri-review and DISPATCH discussions and in the W3C TPAC 2025 breakout session for their feedback.