• Providing links in which the resource is involved not just as a link context but also as a link target, with a different resource being the link context.
• Providing links pertaining to the resource that the server hosting that resource is not aware of.
• External management of links pertaining to the resource in a special-purpose link management service.

• Links are provided in a document that uses a well-defined media type.
• The resource to which the provided links pertain is able to link to the resource that provides these links using a well-known link relation type.

• The format defined in Section 4.1 is nearly identical to the field value of the HTTP "Link" header field as specified in Section 3 of RFC 8288.
• The format defined in Section 4.2 is expressed in [RFC 8259].

• For every link provided in the set of links, explicitly provide the link context using the "anchor" attribute.
• For the link context ("anchor" attribute) and link target ("href" attribute), use URI references that are not relative references (as defined in Section 4.1 of RFC 3986).

• A set of links is represented in JSON as an object that MUST contain "linkset" as its sole member.
• The value of the "linkset" member is an array in which a distinct JSON object -- the "link context object" (see Section 4.2.2) -- is used to represent links that have the same link context.
• Even if there is only one link context object, it MUST be wrapped in an array.

• Each link context object MAY contain an "anchor" member with a value that represents the link context. If present, this value MUST be a URI reference and SHOULD NOT be a relative reference as defined in Section 4.1 of RFC 3986.
• For each distinct relation type that the link context has with link targets, a link context object MUST contain an additional member. The value of this member is an array in which a distinct JSON object -- the "link target object" (see Section 4.2.3) -- MUST be used for each link target for which the relationship with the link context (value of the encompassing "anchor" member) applies. The name of this member expresses the relation type of the link as follows:
  • For registered relation types (Section 2.1.1 of RFC 8288), the name of this member is the registered name of the relation type.
  • For extension relation types (Section 2.1.2 of RFC 8288), the name of this member is the URI that uniquely represents the relation type.
• Even if there is only one link target object, it MUST be wrapped in an array.

• Each link target object MUST contain an "href" member with a value that represents the link target. This value MUST be a URI reference and SHOULD NOT be a relative reference as defined in Section 4.1 of RFC 3986. Cases where the "href" member is present but no value is provided for it (i.e., the resource providing the set of links is the target of the link in the link target object) MUST be handled by providing an "href" member with an empty string as its value ("href": "").
• In many cases, a link target is further qualified by target attributes. Various types of attributes exist, and they are conveyed as additional members of the link target object as detailed in Section 4.2.4.

{ "linkset":
  [
    { "anchor": "https://example.net/bar",
      "next": [
        {"href": "https://example.com/foo"}
      ]
    }
  ]
}

{ "linkset":
  [
    { "anchor": "https://example.net/bar",
      "item": [
        {"href": "https://example.com/foo1"},
        {"href": "https://example.com/foo2"}
      ]
    }
  ]
}

{ "linkset":
  [
    { "anchor": "https://example.net/bar",
      "next": [
        {"href": "https://example.com/foo1"}
      ]
    },
    { "anchor": "https://example.net/boo",
      "https://example.com/relations/baz" : [
        {"href": "https://example.com/foo2"}
      ]
    }
  ]
}

• Serialization-defined attributes as described in Section 3.4.1 of RFC 8288.
• Extension attributes defined and used by communities as allowed by Section 3.4.2 of RFC 8288.
• Internationalized versions of the "title" attribute as defined by [RFC 8288] and of extension attributes allowed by Section 3.4 of RFC 8288.

"hreflang":

The "hreflang" target attribute, defined as optional and repeatable by [RFC 8288], MUST be represented by an "hreflang" member, its value MUST be an array (even if there is only one value to be represented), and each value in that array MUST be a string -- representing one value of the "hreflang" target attribute for a link -- that follows the same model as the syntax discussed in [RFC 8288].

"media":

The "media" target attribute, defined as optional and not repeatable by [RFC 8288], MUST be represented by a "media" member in the link target object, and its value MUST be a string that follows the same model as the syntax discussed in [RFC 8288].

"title":

The "title" target attribute, defined as optional and not repeatable by [RFC 8288], MUST be represented by a "title" member in the link target object, and its value MUST be a JSON string.

"title*":

The "title*" target attribute, defined as optional and not repeatable by [RFC 8288], is motivated by character encoding and language issues and follows the model defined in [RFC 8187]. The details of the JSON representation that applies to "title*" are described in Section 4.2.4.2.

"type":

The "type" target attribute, defined as optional and not repeatable by [RFC 8288], MUST be represented by a "type" member in the link target object, and its value MUST be a string that follows the same model as the syntax discussed in [RFC 8288].

{ "linkset":
  [
    { "anchor": "https://example.net/bar",
      "next": [
        { "href":     "https://example.com/foo",
          "type":     "text/html",
          "hreflang": [ "en" , "de" ]
        }
      ]
    }
  ]
}

• An internationalized target attribute is represented as a member of the link context object with the same name (including the "*") as the attribute.
• The character encoding information as prescribed by [RFC 8187] is not preserved; instead, the content of the internationalized attribute is represented as a JSON string.
• The value of the internationalized target attribute is an array that contains one or more JSON objects. The name of one member of such JSON objects is "value", and its value is the actual content (in its unescaped version) of the internationalized target attribute, i.e., the value of the attribute from which the encoding and language information are removed. The name of another, optional member of such JSON objects is "language", and its value is the language tag [RFC 5646] for the language in which the attribute content is conveyed.

{ "linkset":
  [
    { "anchor": "https://example.net/bar",
      "next": [
        { "href":     "https://example.com/foo",
          "type":     "text/html",
          "hreflang": [ "en" , "de" ],
          "title":    "Next chapter",
          "title*":   [ { "value": "nächstes Kapitel" ,
                          "language" : "de" } ]
        }
      ]
    }
  ]
}

• An extension target attribute is represented as a member of the link target object with the same name as the attribute, including the "*" if applicable.
• The value of an extension attribute MUST be represented by an array, even if there is only one value to be represented.
• If the extension target attribute does not have a name with a trailing asterisk, then each value in that array MUST be a JSON string that represents one value of the attribute.
• If the extension attribute has a name with a trailing asterisk (it follows the content model of [RFC 8187]), then each value in that array MUST be a JSON object. The value of each such JSON object MUST be structured as described in Section 4.2.4.2.

{ "linkset":
  [
    { "anchor": "https://example.net/bar",
      "next": [
        { "href": "https://example.com/foo",
          "type": "text/html",
          "foo":  [ "foovalue" ],
          "bar":  [ "barone", "bartwo" ],
          "baz*": [ { "value": "bazvalue" ,
                      "language" : "en" } ]
        }
      ]
    }
  ]
}

Relation Name:

linkset

Description:

The link target of a link with the "linkset" relation type provides a set of links, including links in which the link context of the link participates.

Reference:

RFC 9264

Type name:

application

Subtype name:

linkset

Required parameters:

N/A

Optional parameters:

profile

Encoding considerations:

Linksets are encoded according to the definitions provided in [RFC 8288]. The encoding discussed in [RFC 8288] is based on the general encoding rules specified by HTTP [RFC 9110] and allows specific parameters to be extended by the indication of character encoding and language as defined by [RFC 8187].

Security considerations:

The security considerations of RFC 9264 apply.

Interoperability considerations:

N/A

Published specification:

RFC 9264

Applications that use this media type:

This media type is not specific to any application, as it can be used by any application that wants to interchange Web Links.

Additional information:

Magic number(s):

N/A

File extension(s):

This media type does not propose a specific extension.

Macintosh file type code(s):

TEXT

Person & email address to contact for further information:

Erik Wilde <erik.wilde@dret.net>

Intended usage:

COMMON

Restrictions on usage:

none

Author:

Erik Wilde <erik.wilde@dret.net>

Change controller:

IETF

Type name:

application

Subtype name:

linkset+json

Required parameters:

N/A

Optional parameters:

profile

Encoding considerations:

The encoding considerations of [RFC 8259] apply.

Security considerations:

The security considerations of RFC 9264 apply.

Interoperability considerations:

The interoperability considerations of [RFC 8259] apply.

Published specification:

RFC 9264

Applications that use this media type:

This media type is not specific to any application, as it can be used by any application that wants to interchange Web Links.

Additional information:

Magic number(s):

N/A

File extension(s):

JSON documents often use ".json" as the file extension, and this media type does not propose a specific extension other than this generic one.

Macintosh file type code(s):

TEXT

Person & email address to contact for further information:

Erik Wilde <erik.wilde@dret.net>

Intended usage:

COMMON

Restrictions on usage:

none

Author:

Erik Wilde <erik.wilde@dret.net>

Change controller:

IETF

• The Web Linking model always has an "implicit context", which is the resource of the HTTP interaction. This original context can be lost or can change when self-contained link representations are moved. Changing the context can change the interpretation of links when they have no explicit anchor or when they use relative URIs. Applications may choose to ignore links that have no explicit anchor or that use relative URIs when these are exchanged in standalone resources.
• The model introduced in this specification supports "third-party links", where one party can provide links that have another party's resource as an anchor. Depending on the link semantics and the application context, it is important to verify that there is sufficient trust in that third party to allow it to provide these links. Applications may choose to treat third-party links differently than cases where a resource and the links for that resource are provided by the same party.

[RFC2119]

S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC3986]

T. Berners-Lee, R. Fielding, and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>.

[RFC5234]

D. Crocker, and P. Overell, "Augmented BNF for Syntax Specifications: ABNF", STD 68, RFC 5234, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>.

[RFC5646]

A. Phillips, and M. Davis, "Tags for Identifying Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, September 2009,
<https://www.rfc-editor.org/info/rfc5646>.

[RFC6838]

N. Freed, J. Klensin, and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>.

[RFC8174]

B. Leiba, "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017,
<https://www.rfc-editor.org/info/rfc8174>.

[RFC8187]

J. Reschke, "Indicating Character Encoding and Language for HTTP Header Field Parameters", RFC 8187, DOI 10.17487/RFC8187, September 2017,
<https://www.rfc-editor.org/info/rfc8187>.

[RFC8259]

T. Bray, "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.

[RFC8288]

M. Nottingham, "Web Linking", RFC 8288, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>.

[RFC9110]

R. Fielding, M. Nottingham, and J. Reschke, "HTTP Semantics", STD 97, RFC 9110, DOI 10.17487/RFC9110, June 2022,
<https://www.rfc-editor.org/info/rfc9110>.

[W3C.REC-json-ld]

M. Sporny, G. Kellogg, and M. Lanthaler, "JSON-LD 1.1: A JSON-based Serialization for Linked Data", July 2020,
<https://www.w3.org/TR/json-ld/>.

[DCMI-TERMS]

Dublin Core Metadata Initiative, "JSON-LD 1.1: A JSON-based Serialization for Linked Data", January 2020,
<https://www.dublincore.org/specifications/dublin-core/dcmi-terms/>.

[RFC5988]

M. Nottingham, "Web Linking", RFC 5988, DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>.

[RFC6690]

Z. Shelby, "Constrained RESTful Environments (CoRE) Link Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>.

[RFC6906]

E. Wilde, "The 'profile' Link Relation Type", RFC 6906, DOI 10.17487/RFC6906, March 2013,
<https://www.rfc-editor.org/info/rfc6906>.

[RFC7284]

M. Lanthaler, "The Profile URI Registry", RFC 7284, DOI 10.17487/RFC7284, June 2014,
<https://www.rfc-editor.org/info/rfc7284>.

[W3C.REC-rdf11-concepts]

R. Cyganiak, D. Wood, and M. Lanthaler, "RDF 1.1 Concepts and Abstract Syntax", February 2014,
<https://www.w3.org/TR/rdf11-concepts/>.

Erik Wilde

Herbert Van de Sompel