Visual RFC.
ALL RFCs / RFC 8288
Read the RFC ↗
RFC 8288 / WEB LINKING

Registered names and extension relations

04

A short registered name and an absolute extension URI can both identify link semantics; neither is a command to fetch documentation.

RFC 8288 · § 2.1EXAMPLE
3 / 3
Registered names and extension relationsA registered next name is compared case-insensitively but generated using lowercase syntax. An absolute fictional extension URI identifies semantics and should not be fetched automatically. A single rel value containing both identifiers creates two typed edges with the same context and target, not duplicate parameters or extra targets.Relation names identify semanticsRegistered names and absolute extension URIsrel="next https://rels.example/picnic"Two links · same context, target and attributesContext /bookTarget /nextnexthttps://rels.example/picnicTwo meanings, not two target downloadsrev is deprecated; compare extension identifiers as specified
03
Expand one rel value into two links.

rel="next https://rels.example/picnic" describes two links between the same context and target. It is one parameter containing a space-separated list, not a duplicate rel.

Source for this drawing: RFC 8288 · Read RFC section 2.1 ↗

Protocol participantThreat or exceptionProtocol controlSimplified drawings · precise section references
New to this? Start hereA quick picture + helpful background

A message needs an address.

Think of a packet as a small addressed envelope. Devices pass it onward; transport protocols decide what delivery promises an application gets.

Helpful first, if these ideas are unfamiliar

These pictures are analogies to help you learn. The linked RFC explains the actual rules.

Terms in this drawing
Relation type
The semantics of the connection between context and target.
Extension relation
An application-defined relation identified by an absolute URI in a Link field.
Related RFCs and changes

“Updates” changes part of an earlier RFC. “Obsoletes” replaces it. This list shows selected related documents.

KEY POINT

Registered relation names follow the reg-rel-type syntax and MUST be compared character by character case-insensitively. The registry uses Specification Required review and stable, freely available specifications.

  • Registered relation names follow the reg-rel-type syntax and MUST be compared character by character case-insensitively. The registry uses Specification Required review and stable, freely available specifications.
  • An extension relation in an HTTP Link field is REQUIRED to be an absolute URI. Extension relation identifiers MUST be compared as case-insensitive strings; all-lowercase URIs SHOULD be used.
  • Clients SHOULD NOT automatically access an extension relation URI just because it identifies a relation. Its identifier and the link target have different roles.
  • Relation types SHOULD NOT infer extra meaning from presence/absence of other types or cardinality; the alternate/stylesheet combination is a historical HTML exception. The reverse-direction rev parameter is deprecated.
DETAILS

Generate lowercase registered names. Case-insensitive comparison is the specified comparison behavior, not a reason to broaden the lowercase generation grammar. The fictional extension https://rels.example/picnic is assumed controlled by its defining application, not registered by this guide. Quote relation values when token syntax cannot represent their characters. Do not prepend a made-up registry base to a registered name and assume equivalent semantics.

Read the RFC section ↗

All chapters in RFC 8288

Drawing view

Scroll the drawing to see every part. Playback controls stay above it.

RFC 9700 / CHAPTERS

Chapters

For full details, tables, algorithms, and exceptions, read the original RFC.

RFC status and corrections ↗