Web Linking
Extracted elements (28)
Relation types are defined as URIs rather than IRIs to simplify and reduce errors in comparison. They are not expected to be displayed to end users, so the internationalization benefit of IRIs does not apply.
The Link header was removed from RFC 2616 (HTTP/1.1) due to lack of implementation experience. RFC 5988 re-specifies it with updated but backwards-compatible syntax because implementations reappeared and new use cases emerged, addressing the unclear status that led some to mint application-specific HTTP headers instead.
The link relation registry from Atom (RFC 4287) is broadened to a format-independent registry to allow typed links that are independent of their serialisation (HTML, Atom, HTTP headers), especially useful when a resource has representations in multiple formats.
The 'rev' parameter (reverse relation) is deprecated because it often confuses authors and readers. In most cases, using a separate named relation type in the forward direction is preferable to expressing reversal via 'rev'.
In HTML4, the combination of 'alternate' and 'stylesheet' relation types in the same link has special meaning and should be serialised in a Link header as a single rel value with both types (e.g., rel="alternate stylesheet") to preserve this relationship.
Target IRIs and anchor parameter values must be converted to URIs before inclusion in the Link HTTP header, since the header does not support IRIs. Conversion follows RFC 3987 Section 3.1.
When serialising Atom atom:link into a Link header, registered relation types serialised as absolute URIs (e.g., 'http://www.iana.org/assignments/relation/self') SHOULD be converted to their short registered form (e.g., 'self') to avoid being mistaken for extension relation types.
Clients SHOULD NOT automatically access the URI of an extension relation type to obtain its definition, in order to avoid overburdening the URI's server.
Extension relation types are REQUIRED to be absolute URIs in Link headers, and MUST be quoted if they contain a semicolon (';') or comma (','), as these are used as delimiters in the header.
If a URI-Reference in a link-value is relative, parsers MUST resolve it as per RFC 3986 Section 5. The base IRI from the message body content is NOT applied; only the request URI is used.
If both 'title' and 'title*' parameters appear in a link-value, processors SHOULD use the 'title*' parameter's value, as it supports non-ASCII characters and language tagging per RFC 5987.
Registered relation type names MUST conform to the reg-rel-type rule (LOALPHA *( LOALPHA | DIGIT | '.' | '-' )) and MUST be compared character-by-character in a case-insensitive fashion.
Registered relation types MUST NOT constrain the media type of the context IRI, and MUST NOT constrain the available representation media types of the target IRI.
Relation types SHOULD NOT infer any additional semantics based upon the presence or absence of another link relation type, or its own cardinality of occurrence. The 'alternate'+'stylesheet' combination is an exception for historical HTML reasons.
The 'rel' parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored by parsers.
The 'title' parameter MUST NOT appear more than once in a given link-value; occurrences after the first MUST be ignored. Similarly, 'title*' MUST NOT appear more than once.
There MUST NOT be more than one 'type' parameter and MUST NOT be more than one 'media' parameter in a link-value. The 'media' parameter value MUST be quoted if it contains a semicolon or comma.
When an anchor parameter is present, consuming implementations MUST NOT process the link without applying it. They may choose to ignore such links entirely, but partial processing (ignoring the anchor) is forbidden.
When extension relation types are compared, they MUST be compared as strings in a case-insensitive fashion, character-by-character (after converting to URIs if serialised in a different form). All-lowercase URIs SHOULD be used for extension relations.
A link is a typed connection between two resources identified by IRIs, comprising: a context IRI, a link relation type, a target IRI, and optionally target attributes. It can be read as '{context IRI} has a {relation type} resource at {target IRI}, which has {target attributes}'.
Target attributes on a link-value include: hreflang (language hint for dereferenced resource), media (intended destination medium for style), title (human-readable label in quoted-string), title* (RFC 5987-encoded label with charset/language), type (media type hint), and arbitrary link-extensions.
This specification establishes the Link Relation Application Data registry, allowing per-application metadata to be attached to entries in the Link Relation Type registry. Registration requires Specification Required with a Designated Expert; each entry requires an Application Name, Description, and Default Value.
This specification establishes the Link Relation Type registry, superseding the Atom 'Registry of Link Relations'. Registration requires Specification Required with a Designated Expert. The initial registry contains ~35 entries drawn from HTML4 and various Atom-related RFCs (e.g., alternate, next, prev, self, enclosure, edit, license, hub).
This specification updates the HTTP Message Header registry entry for 'Link' (RFC 3864) to refer to RFC 5988, giving the Link header field formal standard status.
Applications that automatically follow, trust, or otherwise use links gathered from HTTP headers open attack vectors. In particular, Link headers using the 'anchor' parameter to associate a link's context with another resource should be treated with due caution.
The content of the Link header field is not secure, private, or integrity-guaranteed. Use of TLS with HTTP (RFC 2818/RFC 2817) is currently the only end-to-end way to provide such protection.
The Link header makes extensive use of IRIs and URIs; implementors should consult RFC 3987 for IRI security considerations, RFC 3986 for URI security considerations, and RFC 2616 for HTTP header security considerations.
The Link header field is defined as: Link = "Link" ":" #link-value, where link-value = "<" URI-Reference ">" *( ";" link-param ). Parameters include rel, anchor, rev, hreflang, media, title, title*, type, and link-extensions. Multiple link-values are comma-separated.