JSON serialization for Web Linking
draft-pot-json-link-00

Abstract

This specification defines a serialization of Web Linking [RFC8288] in the JSON [RFC8259] format.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on July 2, 2020.

Copyright Notice

Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved.

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

1. Introduction

There are many JSON-based standards and formats that require the need to express a link. Examples can be found in [draft-kelly-json-hal], [JSON-API], [WEBTHING], [draft-nottingham-json-home], [COLLECTIONJSON], [SIREN] and many others.

Typically when new formats requiring links are defined, there is no common reference to build on. This often results in minor differences between serializations making it difficult to write generic parsers.

This document is an attempt to define a standard JSON serialization for Web linking. A primary goal is to define a format that’s relatively uncontroversial and similar to existing serializations.

2. Format

2.1. The link object.

A link will be encoded as a JSON [RFC8259] object. The object might support the properties from the following chapters, but only rel and href are required.

2.1.1. rel

The rel property refers to Section 3.3 of [RFC8288]. The rel property must be a string.

There is no support to encode multiple relation types for a single link. To encode multiple relation types, the link must appear multiple times in the document.

2.1.2. href

The href property refers to the Link Target, defined in Section 3.1 of [RFC8288].

The property is required and must be specified as a string.

2.1.3. anchor

The anchor attribute is defined in Section 3.2 of [RFC8288]. This specification alters the behavior of anchor. By default, if anchor is not specified the link context is considered to be the URL of the representation it is associated with.

If the link appears in a list of links (defined in Section 2.2), and the list contains a link with relation type ‘self’, the target of the self link MUST be used as the default link context.

If the link is not part of a list of links that has a link relation of type ‘self’, the default behavior is to use the URL of the representation it’s associated with.

However, implementors of this specification MAY override this. Because JSON links may have deeper contextual meaning depending on where it appears in the document.

2.1.4. Other attributes

The link object may also encode the hreflang, media, type attributes. These properties are all defined in Section 3.4.1 of [RFC8288]. In their JSON serialization they are all optional, and must be encoded as a string.

Section 3.4.1 also defines a title* attribute, which may contain an alternative encoding for the title attribute.

JSON only supports UTF-8 encoding. As such, it is not needed to make this distinction. The link title is always encoded using the title property.

2.1.5. Extension Attributes

Similar to [RFC8288], other documents may define new target attributes for links. Parsers that don’t understand any attributes appearing on a link MUST ignore them.

2.1.6. Example

This section is non-normative.

{
  "href": "https://evertpot.com/",
  "rel": "author",
  "title": "Evert Pot"
}

2.2. Lists of links

A list of links defined as a JSON array of one or more link objects.

2.2.1. Example

This section is non-normative.

[
  {
    "href": "https://evertpot.com/",
    "rel": "author",
    "title": "Evert Pot"
  },
  {
    "href": "https://test.example/",
    "rel": "self"
  }
}

2.3. Document-level links

If a JSON representation wants to define document-level links, implementors of this specification SHOULD use a top-level “links” property to define these.

The “links” property contains a list of links.

The links appearing in this list are considered semantically equivalent to the links appear in the Link header, as defined in Section 3.5 of [RFC8288].

Implementors of this specification MAY make an effort to expose links from the HTTP Link header and the document-level links via a unified interface.

2.3.1. Example

This section is non-normative.

{
  "links": [ 
    {
      "href": "https://evertpot.com/",
      "rel": "author",
      "title": "Evert Pot"
    },
    {
      "href": "https://test.example/",
      "rel": "self"
    }
  ]
}

3. IANA considerations

We would like to register the ‘application/links+json’ media-type for documents wishing to implement this spec.

TBD?

4. References

4.1. Normative References

4.2. Informative References

Appendix A. Typescript definitions

type Link = {
  href: string,
  rel: string,
  anchor?: string,
  hreflang?: string,
  media?: string,
  type?: string,
}

type LinkSet = Link[];

type DocumentLinks = {
  links: LinkSet
}

Appendix B. JSON-SCHEMA definitions

TBD

Appendix C. Changelog

C.1. Changes since -??

Author's Address

Table of Contents

• 1. Introduction
• 2. Format
• 2.1. The link object.
• 2.1.1. rel
• 2.1.2. href
• 2.1.3. anchor
• 2.1.4. Other attributes
• 2.1.5. Extension Attributes
• 2.1.6. Example
• 2.2. Lists of links
• 2.2.1. Example
• 2.3. Document-level links
• 2.3.1. Example
• 3. IANA considerations
• 4. References
• 4.1. Normative References
• 4.2. Informative References
• Appendix A. Typescript definitions
• Appendix B. JSON-SCHEMA definitions
• Appendix C. Changelog
• C.1. Changes since -??
• Author's Address