rfc-9264

Linkset: Media Types and a Link Relation Type for Link Sets

E. Wilde, H. Van de Sompel
date2022-07 streamIETF areawit wghttpapi statusPROPOSED STANDARD pages31 canonicalhttps://www.rfc-editor.org/rfc/rfc9264 doi10.17487/RFC9264
This specification defines two formats and associated media types for representing sets of links as standalone documents. One format is based on JSON, and the other is aligned with the format for representing links in the HTTP "Link" header field. This specification also introduces a link relation type to support the discovery of sets of links.

Extracted elements (30)

design-rationale §4.2.4.3

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.

http, json

design-rationale §3.2

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.

http

design-rationale §4.1

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.

http

design-rationale §3

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.

http, json

interoperability-note §4.1

'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.

http

interoperability-note §4

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'.

http

normative-requirement §4.2.1 MUST

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.

http, json

normative-requirement §6 MUST

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.

http

normative-requirement §4.2 MUST

'application/linkset+json' link sets MUST be encoded using UTF-8 in the interests of interoperability.

http, json

normative-requirement §4.2.5 MUST NOT

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.

http, json

normative-requirement §4 RECOMMENDED

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.

http, json

normative-requirement §4.2.4.2 MUST

Implementations MUST properly decode/encode internationalized target attributes following the RFC 8187 model when transcoding between 'application/linkset' and 'application/linkset+json' formats.

http, json

normative-requirement §5 MUST

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.

http, registry

normative-requirement §6 MUST

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.

http

normative-requirement §4.1 MUST

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.

http

protocol-element §4.2.2

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.

http, json

protocol-element §4.2.3

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.

http, json

protocol-element §4.2

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.

http, json

protocol-element §4.1

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.

http, json

protocol-element §6

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.

http, registry

protocol-element §5

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.

http, registry

registry §8.3

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.

registry, http, json

registry §8.2

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.

registry, http

registry §8.1

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.

registry, http

security-consideration §9

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.

security, http

security-consideration §9

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.

security, http

security-consideration §9

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.

security, http

wire-format §4.2.4.3

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.

http, json

wire-format §4.2.4.1

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.

http, json

wire-format §4.2.4.2

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.

http, json