The "dereferenceable identifier" pattern

2.1. Protocol and Protocol Version identifiers

Many protocols based on XML or JSON include a protocol or protocol version identifier in the heading to a data item.¶

E.g., [JSO] defines a language for data models that contain an identifier to the language version in use, here https://json-schema.org/draft/2020-12/schema. The model that can be retrieved from this URI in turn contains further dereferenceable identifiers that point to further details.¶

Section 8.1.1 of [JSO] has this:¶

If this URI identifies a retrievable resource, that resource SHOULD be of media type "application/schema+json".¶

So it acknowledges that the dereferenceability is optional, but does place further restrictions on what can be the result of a successful dereference: another one of these data models, which in turn contain further dereferenceable identifiers.¶

2.2. Concept identifiers

The problem details format [PROBLEM] uses a dereferenceable identifier for its "type" field. The value is a URI that "identifies the specific "problem type" (e.g., "out of credit")" (Section 1 of [PROBLEM]).¶

Section 3.1.1 of [PROBLEM] has this:¶

If the type URI is a locator (e.g., those with a "http" or "https" scheme), dereferencing it SHOULD provide human-readable documentation for the problem type (e.g., using HTML [HTML5]).¶

but then warns:¶

However, consumers SHOULD NOT automatically dereference the type URI, unless they do so when providing information to developers (e.g., when a debugging tool is in use).¶

Section 5 of [PROBLEM] further details:¶

A problem's type URI SHOULD resolve to HTML [HTML5] documentation that explains how to resolve the problem.¶

This becomes even more interesting as Section 5.2 of [PROBLEM] then gives this advice:¶

Registrations MAY use the prefix "https://iana.org/assignments/http- problem-types#" for the type URI.¶

A reference to the place where registrations for these items are managed is certainly desirable, however, the implications on the management of fragment identifiers in the HTML documents that IANA generates from registration information are an example for the increased complexity dereferenceable identifiers may place on the owners of the URI space employed.¶

2.3. MORE EXAMPLES

There are a lot more examples in published RFCs; add them to this document.¶

3.1. Server overload

If a data item containing dereferenceable identifier(s) becomes widely distributed, naive implementations that handle such a data item might dereference these identifiers as part of a routine operation. Many definitions of dereferenceable identifiers contain admonitions that such a behavior can cause an implosion of requests on the server(s) for the URI.¶

3.2. Longevity of identifiers

Dereferenceable URIs usually contain domain names, whose ownership can change. As a result, and for other reasons as well, parts of the name space of an origin may come under new administration, which can change the policies that apply to resources made available there.¶

These are problems of such URIs in general (and can be mitigated by going to a non-dereferenceable kind of URIs such as one based on the 'tag' uri scheme [TAG]). However, the problems are exacerbated by their use as a dereferenceable identifier. The new owner/administrator might more easily accept that a certain chunk of their URI space should not be used (which suffices for a non-dereferenceable identifier based on this kind of URI namespace) than that certain content needs to be offered there (potentially presenting non-trivial loads, some mechanisms needed to update that information, and legal liabilities that are hard to assess).¶

3.3. Redirect ambiguities

Dereferencing an identifier may involve following some redirections; whether that following is actually implied, or desired (or even desirable) is rarely being discussed.¶