Linkset: Media Types and a Link Relation Type for Link Sets
Extracted elements (30)
Extension target attributes are always treated as repeatable (array-valued) in the JSON serialization because, lacking standardization, their cardinality is unknown to generic applications. This avoids ambiguity when round-tripping between formats.
Standalone link set documents are introduced to address cases where writing to the HTTP 'Link' header field is impractical (no direct header access), the header would be unpredictably large, or links are managed by a third party. HTTP lacks a response error code for truncated 'Link' headers, making header-size management unreliable.
The 'application/linkset' format explicitly differs from RFC 6690 'application/link-format': the former fully matches the RFC 8288 HTTP Link header field grammar, whereas the latter introduces CoRE-specific constraints. They are not interchangeable.
Two serialization formats are defined: one aligned with the HTTP 'Link' header format (for tool reuse and compatibility) and one JSON-based (motivated by widespread JSON tooling). Both address the same abstract Web Linking model from RFC 8288.
'application/linkset' differs from 'application/link-format' (RFC 6690) in that it fully matches the RFC 8288 Link header grammar, whereas RFC 6690 adds CoRE-specific constraints. Implementations targeting both environments must handle the distinction.
The 'rev' construct from RFC 5988 is deprecated by RFC 8288. Both linkset serializations represent inverse links as direct links using 'rel' with the roles of the resources switched, rather than supporting 'rev'.
A set of links in JSON MUST contain 'linkset' as the sole member of the top-level object, and the link context object array MUST be wrapped in an array even when there is only one context object.
A user agent following a 'linkset' link that obtains links with relative-reference anchors or targets MUST determine the context for those links and SHOULD ignore links for which it cannot unambiguously make that determination.
'application/linkset+json' link sets MUST be encoded using UTF-8 in the interests of interoperability.
Extensions other than extension target attributes MUST NOT change the semantics of the JSON members defined in this specification, and agents consuming JSON linkset documents can safely ignore such extensions.
For link sets to be self-contained and usable outside an HTTP interaction, it is RECOMMENDED to provide explicit 'anchor' attributes for every link and to use non-relative URI references for both 'anchor' and 'href'. The 'title*' attribute is RECOMMENDED over 'title' to allow language tagging.
Implementations MUST properly decode/encode internationalized target attributes following the RFC 8187 model when transcoding between 'application/linkset' and 'application/linkset+json' formats.
The value of the 'profile' parameter (and 'profile' attribute on a 'linkset' link) MUST be a non-empty list of space-separated URIs identifying constraints or conventions. Profile URIs MAY be registered in the IANA 'Profile URIs' registry.
User agents MUST process each link in a link set independently, including processing of the link context and link target, and MAY ignore links from the set in which the context of the 'linkset' link does not participate.
When converting an 'application/linkset' document for use as an HTTP 'Link' header field value, newline characters MUST be removed or MUST be replaced by whitespace (SP) to comply with RFC 9110.
A link context object groups links sharing the same context. It MAY contain an 'anchor' member (a URI reference, SHOULD NOT be relative), and MUST contain one member per distinct relation type, whose value is an array of link target objects.
A link target object represents a single link target. It MUST contain an 'href' member whose value is a URI reference (SHOULD NOT be relative); an empty string represents the case where the providing resource is itself the target.
The 'application/linkset+json' media type represents a set of links as a JSON document. The top-level object MUST contain a 'linkset' member whose value is an array of link context objects, each grouping links sharing the same link context.
The 'application/linkset' media type represents a set of links in a format nearly identical to the HTTP 'Link' header field value as specified in RFC 8288, extended to allow newline characters as separators for human readability. Non-ASCII characters are not permitted.
The 'linkset' link relation type identifies a resource that provides a set of links, including links in which the link context participates. A resource MAY provide more than one such link, referring to the same set in different media types or to different sets from third-party services.
The 'profile' parameter MAY be used with 'application/linkset' and 'application/linkset+json' media types to convey specific constraints or conventions applying to a link set document. Its value MUST be a non-empty list of space-separated URIs.
IANA registered the 'application/linkset+json' media type for link sets encoded as JSON. Optional parameter: 'profile'. Encoding follows RFC 8259 (JSON); interoperability considerations of RFC 8259 apply.
IANA registered the 'application/linkset' media type for link sets encoded in the HTTP Link header field format. Optional parameter: 'profile'. Encoding follows RFC 8288.
IANA registered the 'linkset' link relation type in the 'Link Relation Types' registry. The target of such a link provides a set of links including links in which the link context participates.
Links may expose sensitive or 'hidden' URIs not intended for broad sharing. If access to such URIs is meant to be restricted, technical access controls should be applied rather than relying on obscurity, since link sets make URIs explicitly visible.
The implicit context of an HTTP interaction can be lost or changed when self-contained link representations are moved. Links without explicit anchors or using relative URIs may be misinterpreted; applications may choose to ignore such links in standalone resources.
The 'third-party links' model allows one party to provide links with another party's resource as the anchor. Applications MUST consider whether sufficient trust exists in the third party and MAY treat third-party links differently from first-party links.
Extension target attributes (non-RFC 8288-defined attributes) MUST always be represented as arrays in the JSON serialization, since their cardinality is unknown to generic applications. Non-asterisk extensions contain arrays of strings; asterisk-suffixed extensions contain arrays of objects structured as internationalized attributes.
In the JSON serialization, the 'hreflang' target attribute MUST be represented as an array of strings even when only one value is present. The 'media', 'title', and 'type' attributes are single-valued strings; 'title*' is an array of objects with 'value' and optional 'language' members.
Internationalized target attributes (those with a trailing asterisk, following RFC 8187) are serialized in JSON as an array of objects each with a 'value' member (unescaped string content) and an optional 'language' member (BCP 47 language tag). Character encoding information from RFC 8187 is not preserved.