draft-ietf-httpapi-linkset-06.unpg.txt   draft-ietf-httpapi-linkset-latest.txt 
Network Working Group E. Wilde Network Working Group E. Wilde
Internet-Draft Axway Internet-Draft Axway
Intended status: Informational H. Van de Sompel Intended status: Informational H. Van de Sompel
Expires: May 16, 2022 Data Archiving and Networked Services Expires: July 24, 2022 Data Archiving and Networked Services
November 12, 2021 January 20, 2022
Linkset: Media Types and a Link Relation Type for Link Sets Linkset: Media Types and a Link Relation Type for Link Sets
draft-ietf-httpapi-linkset-06 draft-ietf-httpapi-linkset-07
Abstract Abstract
This specification defines two formats and respective media types for This specification defines two formats and respective media types for
representing sets of links as stand-alone documents. One format is representing sets of links as stand-alone documents. One format is
JSON-based, the other aligned with the format for representing links JSON-based, the other aligned with the format for representing links
in the HTTP "Link" header field. This specification also introduces in the HTTP "Link" header field. This specification also introduces
a link relation type to support discovery of sets of links. a link relation type to support discovery of sets of links.
Note to Readers Note to Readers
skipping to change at line 42 skipping to change at page 1, line 43
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/. Drafts is at https://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on May 16, 2022. This Internet-Draft will expire on July 24, 2022.
Copyright Notice Copyright Notice
Copyright (c) 2021 IETF Trust and the persons identified as the Copyright (c) 2022 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(https://trustee.ietf.org/license-info) in effect on the date of (https://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Use Cases and Motivation 3. Use Cases and Motivation . . . . . . . . . . . . . . . . . . 3
3.1. Third-Party Links 3.1. Third-Party Links . . . . . . . . . . . . . . . . . . . . 4
3.2. Challenges Writing to HTTP Link Header Field 3.2. Challenges Writing to HTTP Link Header Field . . . . . . 5
3.3. Large Number of Links 3.3. Large Number of Links . . . . . . . . . . . . . . . . . . 5
4. Document Formats for Sets of Links 4. Document Formats for Sets of Links . . . . . . . . . . . . . 5
4.1. HTTP Link Document Format: application/linkset 4.1. HTTP Link Document Format: application/linkset . . . . . 6
4.2. JSON Document Format: application/linkset+json 4.2. JSON Document Format: application/linkset+json . . . . . 7
4.2.1. Set of Links 4.2.1. Set of Links . . . . . . . . . . . . . . . . . . . . 7
4.2.2. Link Context Object 4.2.2. Link Context Object . . . . . . . . . . . . . . . . . 8
4.2.3. Link Target Object 4.2.3. Link Target Object . . . . . . . . . . . . . . . . . 8
4.2.4. Link Target Attributes 4.2.4. Link Target Attributes . . . . . . . . . . . . . . . 10
4.2.5. JSON Extensibility 4.2.5. JSON Extensibility . . . . . . . . . . . . . . . . . 14
5. The "profile" parameter for media types to Represent Sets of 5. The "profile" parameter for media types to Represent Sets of
Links Links . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
6. The "linkset" Relation Type for Linking to a Set of Links 6. The "linkset" Relation Type for Linking to a Set of Links . . 15
7. Examples 7. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Set of Links Provided as application/linkset 7.1. Set of Links Provided as application/linkset . . . . . . 16
7.2. Set of Links Provided as application/linkset+json 7.2. Set of Links Provided as application/linkset+json . . . . 17
7.3. Discovering a Link Set via the "linkset" Link Relation 7.3. Discovering a Link Set via the "linkset" Link Relation
Type Type . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.4. Link Set Profiles 7.4. Link Set Profiles . . . . . . . . . . . . . . . . . . . . 20
7.4.1. Using a "profile" Attribute with a "linkset" Link 7.4.1. Using a "profile" Attribute with a "linkset" Link . . 20
7.4.2. Using a "profile" Parameter with a Link Set Media 7.4.2. Using a "profile" Parameter with a Link Set Media
Type Type . . . . . . . . . . . . . . . . . . . . . . . . 21
7.4.3. Using a Link with a "profile" Link Relation Type 7.4.3. Using a Link with a "profile" Link Relation Type . . 21
8. IANA Considerations 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22
8.1. Link Relation Type: linkset 8.1. Link Relation Type: linkset . . . . . . . . . . . . . . . 22
8.2. Media Type: application/linkset 8.2. Media Type: application/linkset . . . . . . . . . . . . . 23
8.3. Media Type: application/linkset+json 8.3. Media Type: application/linkset+json . . . . . . . . . . 24
9. Security Considerations 9. Security Considerations . . . . . . . . . . . . . . . . . . . 25
10. References 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
10.1. Normative References 10.1. Normative References . . . . . . . . . . . . . . . . . . 26
10.2. Informative References 10.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. JSON-LD Context Appendix A. JSON-LD Context . . . . . . . . . . . . . . . . . . 28
Appendix B. Implementation Status Appendix B. Implementation Status . . . . . . . . . . . . . . . 33
B.1. GS1 B.1. GS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
B.2. FAIR Signposting Profile B.2. FAIR Signposting Profile . . . . . . . . . . . . . . . . 34
B.3. Open Journal Systems (OJS) B.3. Open Journal Systems (OJS) . . . . . . . . . . . . . . . 34
Acknowledgements Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 34
Authors' Addresses Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 34
1. Introduction 1. Introduction
Resources on the Web often use typed Web Links [RFC8288], either Resources on the Web often use typed Web Links [RFC8288], either
embedded in resource representations, for example using the <link> embedded in resource representations, for example using the <link>
element for HTML documents, or conveyed in the HTTP "Link" header element for HTML documents, or conveyed in the HTTP "Link" header
field for documents of any media type. In some cases, however, field for documents of any media type. In some cases, however,
providing links in this manner is impractical or impossible and providing links in this manner is impractical or impossible and
delivering a set of links as a stand-alone document is preferable. delivering a set of links as a stand-alone document is preferable.
Therefore, this specification defines two document formats that Therefore, this specification defines two formats for representing
serialize Web Links and their attributes. One serializes links in sets of Web Links and their attributes as stand-alone documents. One
the same format as used in HTTP the Link header field, and the other serializes links in the same format as used in HTTP the Link header
as a JSON object. It also defines associated media types to field, and the other serializes links in JSON. It also defines
represent sets of links and the "linkset" relation type that supports associated media types to represent sets of links and the "linkset"
discovery of any resource that conveys a set of links as a stand- relation type that supports discovery of any resource that conveys a
alone document. set of links as a stand-alone document.
2. Terminology 2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119] [RFC8174] when, and only when, they appear in all 14 [RFC2119] [RFC8174] when, and only when, they appear in all
capitals, as shown here. capitals, as shown here.
This specification uses the terms "link context" and "link target" as This specification uses the terms "link context" and "link target" as
skipping to change at line 141 skipping to change at page 3, line 48
In the examples provided in this document, links in the HTTP "Link" In the examples provided in this document, links in the HTTP "Link"
header field are shown on separate lines in order to improve header field are shown on separate lines in order to improve
readability. Note, however, that as per Section 5.5 of readability. Note, however, that as per Section 5.5 of
[I-D.ietf-httpbis-semantics], line breaks are deprecated in values [I-D.ietf-httpbis-semantics], line breaks are deprecated in values
for HTTP fields; only whitespaces and tabs are supported as for HTTP fields; only whitespaces and tabs are supported as
separators. separators.
3. Use Cases and Motivation 3. Use Cases and Motivation
The following sections describe uses cases in which providing links The following sections describe use cases in which providing links by
by means of a standalone document instead of in an HTTP "Link" header means of a standalone document instead of in an HTTP "Link" header
field or as links embedded in the resource representation is field or as links embedded in the resource representation is
advantageous or necessary. advantageous or necessary.
For all scenarios, links could be provided by means of a stand-alone For all scenarios, links could be provided by means of a stand-alone
document that is formatted according to the JSON-based serialization, document that is formatted according to the JSON-based serialization,
the serialization aligned with the HTTP "Link" field format, or both. the serialization aligned with the HTTP "Link" field format, or both.
The former serialization is motivated by the widespread use of JSON The former serialization is motivated by the widespread use of JSON
and related tools, which suggests that handling sets of links and related tools, which suggests that handling sets of links
expressed as JSON documents should be attractive to developers. The expressed as JSON documents should be attractive to developers. The
latter serialization is provided for compatibility with the existing latter serialization is provided for compatibility with the existing
serialization used in the HTTP "Link" field and to allow reuse of serialization used in the HTTP "Link" field and to allow reuse of
tools created to handle it. tools created to handle it.
It is important to keep in mind that when providing links by means of It is important to keep in mind that when providing links by means of
a standalone representation, other links can still be provided using a standalone representation, other links can still be provided using
other approaches, i.e. it is possible combine various mechanisms to other approaches, i.e. it is possible to combine various mechanisms
convey links. to convey links.
3.1. Third-Party Links 3.1. Third-Party Links
In some cases it is useful that links pertaining to a resource are In some cases it is useful that links pertaining to a resource are
provided by a server other than the one that hosts the resource. For provided by a server other than the one that hosts the resource. For
example, this allows: example, this allows:
o Providing links in which the resource is involved not just as link o Providing links in which the resource is involved not just as link
context but also as link target. context but also as link target.
skipping to change at line 253 skipping to change at page 6, line 17
directionality that is the inverse of direct links that use the "rel" directionality that is the inverse of direct links that use the "rel"
construct. In both serializations for link sets defined here, construct. In both serializations for link sets defined here,
inverse links may be represented as direct links using the "rel" inverse links may be represented as direct links using the "rel"
construct and by switching the position of the resources involved in construct and by switching the position of the resources involved in
the link. the link.
4.1. HTTP Link Document Format: application/linkset 4.1. HTTP Link Document Format: application/linkset
This document format is near identical to the field value of the HTTP This document format is near identical to the field value of the HTTP
"Link" header field as defined in Section 3 of [RFC8288], more "Link" header field as defined in Section 3 of [RFC8288], more
specifically by its ABNF production rule for "Link" and subsequent specifically by its ABNF [RFC5234] production rule for "Link" and
ones. It differs only from the format for field values of the HTTP subsequent ones. It differs only from the format for field values of
"Link" header in that not only spaces and horizontal tabs are allowed the HTTP "Link" header in that not only spaces and horizontal tabs
as separators but also newline characters as a means to improve are allowed as separators but also newline characters as a means to
usability. The use of non-ASCII characters in the field value of the improve readability for humans. The use of non-ASCII characters in
HTTP "Link" Header field is not interoperable. the field value of the HTTP "Link" Header field is not allowed.
The assigned media type for this format is "application/linkset". The assigned media type for this format is "application/linkset".
When converting an "application/linkset" document to a field value When converting an "application/linkset" document to a field value
for the HTTP "Link" header, newline characters SHOULD be removed in for the HTTP "Link" header, newline characters SHOULD be removed in
order to comply with Section 5.5 of [I-D.ietf-httpbis-semantics]. order to comply with Section 5.5 of [I-D.ietf-httpbis-semantics].
In order to support use cases where "application/linkset" documents In order to support use cases where "application/linkset" documents
are re-used outside the context of an HTTP interaction, it is are re-used outside the context of an HTTP interaction, it is
RECOMMENDED to make them self-contained by adhering to the following RECOMMENDED to make them self-contained by adhering to the following
skipping to change at line 314 skipping to change at page 7, line 30
the link context using the "anchor" member. the link context using the "anchor" member.
o For link context ("anchor" member) and link target ("href" o For link context ("anchor" member) and link target ("href"
member), use URI references that are not relative references (as member), use URI references that are not relative references (as
defined in Section 4.1 of [RFC3986]). defined in Section 4.1 of [RFC3986]).
If these recommendations are not followed, interpretation of If these recommendations are not followed, interpretation of
"application/linkset+json" will depend on which URI is used as "application/linkset+json" will depend on which URI is used as
context URI. context URI.
The "application/linkset+json" serialization is designed such that it The "application/linkset+json" serialization allows for OPTIONAL
can directly be used as the content of a JSON-LD serialization by support of a JSON-LD [W3C.REC-json-ld-20140116] serialization. This
adding an appropriate context. Appendix A shows an example of a can be achieved by adding an appropriate context to the "application/
possible context that, when added to a JSON serialization, allows it linkset+json" serialization using the approach described in
to be interpreted as RDF. [W3C.REC-json-ld-20140116]. Communities of practice can decide which
context best meets their application needs. Appendix A shows an
example of a possible context that, when added to a JSON
serialization, allows it to be interpreted as Resource Description
Framework (RDF) [W3C.REC-rdf11-concepts-20140225] data.
4.2.1. Set of Links 4.2.1. Set of Links
In the JSON representation of a set of links: In the JSON representation of a set of links:
o A set of links is represented as a JSON object which MUST have o A set of links is represented in JSON as an object which MUST
"linkset" as its sole member. contain "linkset" as its sole member.
o The "linkset" member is an array in which a distinct JSON object - o The "linkset" member is an array in which a distinct JSON object -
the "link context object" (see Section 4.2.2) - is used to the "link context object" (see Section 4.2.2) - is used to
represent links that have the same link context. represent links that have the same link context.
o Even if there is only one link context object, it MUST be wrapped o Even if there is only one link context object, it MUST be wrapped
in an array. in an array.
4.2.2. Link Context Object 4.2.2. Link Context Object
In the JSON representation one or more links that have the same link In the JSON representation one or more links that have the same link
context are represented by a JSON object, the link context object. A context are represented by a JSON object, the link context object. A
link context object adheres to the following rules: link context object adheres to the following rules:
o Each link context object MAY have an "anchor" member with a value o Each link context object MAY contain an "anchor" member with a
that represents the link context. If present, this value MUST be value that represents the link context. If present, this value
a URI reference and SHOULD NOT be a relative reference as per MUST be a URI reference and SHOULD NOT be a relative reference as
Section 4.1 of [RFC3986]. per Section 4.1 of [RFC3986].
o For each distinct relation type that the link context has with o For each distinct relation type that the link context has with
link targets, a link context object MUST have an additional link targets, a link context object MUST contain an additional
member. This member is an array in which a distinct JSON object - member. This member is an array in which a distinct JSON object -
the "link target object" (see Section 4.2.3) - MUST be used for the "link target object" (see Section 4.2.3) - MUST be used for
each link target for which the relationship with the link context each link target for which the relationship with the link context
(value of the encompassing anchor member) applies. The name of (value of the encompassing anchor member) applies. The name of
this member expresses the relation type of the link as follows: this member expresses the relation type of the link as follows:
* For registered relation types (Section 2.1.1 of [RFC8288]), the * For registered relation types (Section 2.1.1 of [RFC8288]), the
name of this member is the registered name of the relation name of this member is the registered name of the relation
type. type.
skipping to change at line 370 skipping to change at page 8, line 41
o Even if there is only one link target object it MUST be wrapped in o Even if there is only one link target object it MUST be wrapped in
an array. an array.
4.2.3. Link Target Object 4.2.3. Link Target Object
In the JSON representation a link target is represented by a JSON In the JSON representation a link target is represented by a JSON
object, the link target object. A link target object adheres to the object, the link target object. A link target object adheres to the
following rules: following rules:
o Each link target object MUST have an "href" member with a value o Each link target object MUST contain an "href" member with a value
that represents the link target. This value MUST be a URI that represents the link target. This value MUST be a URI
reference and SHOULD NOT be a relative reference as per reference and SHOULD NOT be a relative reference as per
Section 4.1 of [RFC3986]. Cases where the href member is present, Section 4.1 of [RFC3986]. Cases where the href member is present,
but no value is provided for it (i.e. the resource providing the 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) 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 MUST be handled by providing an "href" member with an empty string
("href": ""). ("href": "").
o In many cases, a link target is further qualified by target o In many cases, a link target is further qualified by target
attributes. Various types of attributes exist and they are attributes. Various types of attributes exist and they are
skipping to change at line 626 skipping to change at page 14, line 25
} }
] ]
} }
] ]
} }
4.2.5. JSON Extensibility 4.2.5. JSON Extensibility
The Web linking model ([RFC8288]) provides for the use of extension The Web linking model ([RFC8288]) provides for the use of extension
target attributes as discussed in Section 4.2.4.3. No other form of target attributes as discussed in Section 4.2.4.3. No other form of
extensions SHOULD be used. In case they are used nevertheless, they extensions SHOULD be used. This limitation of the JSON format allows
MUST NOT change the semantics of the JSON members defined in this to unambiguously round trip between links provided in the HTTP "Link"
specification. Agents that consume JSON linkset documents MUST header field, sets of links serialized according to the "application/
ignore such extensions. linkset" format, and sets of links serialized according to the
"application/linkset+json" format.
This limitation of the JSON format allows to unambiguously round trip Cases may exist in which the use of extensions other than those of
between links provided in the HTTP "Link" header field, sets of links Section 4.2.4.3 may be useful. For example, when a link set
serialized according to the "application/linkset" format, and sets of publishers needs to include descriptive or technical metadata for
links serialized according to the "application/linkset+json" format. internal consumption. In case such extensions are used they MUST NOT
change the semantics of the JSON members defined in this
specification. Agents that consume JSON linkset documents can safely
ignore such extensions.
5. The "profile" parameter for media types to Represent Sets of Links 5. The "profile" parameter for media types to Represent Sets of Links
As a means to convey specific constraints or conventions (as per As a means to convey specific constraints or conventions (as per
[RFC6906]) that apply to a link set document, the "profile" parameter [RFC6906]) that apply to a link set document, the "profile" parameter
MAY be used in conjunction with the media types "application/linkset" MAY be used in conjunction with the media types "application/linkset"
and "application/linkset+json" detailed in Section 4.1 and and "application/linkset+json" detailed in Section 4.1 and
Section 4.2, respectively. For example, the parameter could be used Section 4.2, respectively. For example, the parameter could be used
to indicate that a link set uses a specific, limited set of link to indicate that a link set uses a specific, limited set of link
relation types. relation types.
skipping to change at line 870 skipping to change at page 20, line 16
Date: Mon, 12 Aug 2019 10:45:54 GMT Date: Mon, 12 Aug 2019 10:45:54 GMT
Server: Apache-Coyote/1.1 Server: Apache-Coyote/1.1
Link: <https://example.org/links/resource1> Link: <https://example.org/links/resource1>
; rel="linkset" ; rel="linkset"
; type="application/linkset+json" ; type="application/linkset+json"
Content-Length: 236 Content-Length: 236
Content-Type: text/html;charset=utf-8 Content-Type: text/html;charset=utf-8
Figure 6: Response to HTTP HEAD request Figure 6: Response to HTTP HEAD request
Section 7.2 shows a client obtaining a set of links by issuing an
HTTP GET on the target of the link with the "linkset" relation type,
<https://example.org/links/resource1>.
7.4. Link Set Profiles 7.4. Link Set Profiles
The examples in this section illustrate the use of the "profile" The examples in this section illustrate the use of the "profile"
attribute for a link with the "linkset" link relation type and the attribute for a link with the "linkset" link relation type and the
"profile" attribute for a link set media type. The examples are "profile" attribute for a link set media type. The examples are
inspired by the implementation of link sets by GS1 (the standards inspired by the implementation of link sets by GS1 (the standards
body behind many of the world's barcodes). body behind many of the world's barcodes).
7.4.1. Using a "profile" Attribute with a "linkset" Link 7.4.1. Using a "profile" Attribute with a "linkset" Link
skipping to change at line 928 skipping to change at page 21, line 31
discovered through the HTTP interactions shown in Section 7.4.1. discovered through the HTTP interactions shown in Section 7.4.1.
HEAD /01/9506000134352?linkType=all HTTP/1.1 HEAD /01/9506000134352?linkType=all HTTP/1.1
Host: id.gs1.org Host: id.gs1.org
Figure 9: Client HTTP HEAD request Figure 9: Client HTTP HEAD request
Figure 10 shows the server's response to the request of Figure 9. Figure 10 shows the server's response to the request of Figure 9.
Note the "profile" parameter for the application/linkset+json media Note the "profile" parameter for the application/linkset+json media
type, which has as value the same Profile URI <https://www.gs1.org/ type, which has as value the same Profile URI <https://www.gs1.org/
voc/?show=linktypes> as was used in xref target="Response_pr_at"/>. voc/?show=linktypes> as was used in <xref target="Response_pr_at"/>.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Date: Mon, 27 Sep 2021 16:03:33 GMT Date: Mon, 27 Sep 2021 16:03:33 GMT
Server: nginx Server: nginx
Content-Type: application/linkset+json; profile="https://www.gs1.org/voc/?show=linktypes" Content-Type: application/linkset+json; profile="https://www.gs1.org/voc/?show=linktypes"
Content-Length: 396 Content-Length: 396
Figure 10: Response to the client's HEAD request including a Figure 10: Response to the client's HEAD request including a
"profile" parameter for the "application/linkset+json" media type "profile" parameter for the "application/linkset+json" media type
skipping to change at line 1150 skipping to change at page 26, line 24
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66,
RFC 3986, DOI 10.17487/RFC3986, January 2005, RFC 3986, DOI 10.17487/RFC3986, January 2005,
<https://www.rfc-editor.org/info/rfc3986>. <https://www.rfc-editor.org/info/rfc3986>.
[RFC5234] Crocker, D., Ed. 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] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying
Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646,
September 2009, <https://www.rfc-editor.org/info/rfc5646>. September 2009, <https://www.rfc-editor.org/info/rfc5646>.
[RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link
Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, Format", RFC 6690, DOI 10.17487/RFC6690, August 2012,
<https://www.rfc-editor.org/info/rfc6690>. <https://www.rfc-editor.org/info/rfc6690>.
[RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type
Specifications and Registration Procedures", BCP 13, Specifications and Registration Procedures", BCP 13,
RFC 6838, DOI 10.17487/RFC6838, January 2013, RFC 6838, DOI 10.17487/RFC6838, January 2013,
<https://www.rfc-editor.org/info/rfc6838>. <https://www.rfc-editor.org/info/rfc6838>.
[RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906, [RFC6906] Wilde, E., "The 'profile' Link Relation Type", RFC 6906,
DOI 10.17487/RFC6906, March 2013, DOI 10.17487/RFC6906, March 2013,
<https://www.rfc-editor.org/info/rfc6906>. <https://www.rfc-editor.org/info/rfc6906>.
[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", RFC 6982,
DOI 10.17487/RFC6982, July 2013,
<https://www.rfc-editor.org/info/rfc6982>.
[RFC7284] Lanthaler, M., "The Profile URI Registry", RFC 7284, [RFC7284] Lanthaler, M., "The Profile URI Registry", RFC 7284,
DOI 10.17487/RFC7284, June 2014, DOI 10.17487/RFC7284, June 2014,
<https://www.rfc-editor.org/info/rfc7284>. <https://www.rfc-editor.org/info/rfc7284>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8187] Reschke, J., "Indicating Character Encoding and Language [RFC8187] Reschke, J., "Indicating Character Encoding and Language
for HTTP Header Field Parameters", RFC 8187, for HTTP Header Field Parameters", RFC 8187,
skipping to change at line 1196 skipping to change at page 27, line 21
Interchange Format", STD 90, RFC 8259, Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017, DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>. <https://www.rfc-editor.org/info/rfc8259>.
[RFC8288] Nottingham, M., "Web Linking", RFC 8288, [RFC8288] Nottingham, M., "Web Linking", RFC 8288,
DOI 10.17487/RFC8288, October 2017, DOI 10.17487/RFC8288, October 2017,
<https://www.rfc-editor.org/info/rfc8288>. <https://www.rfc-editor.org/info/rfc8288>.
10.2. Informative References 10.2. Informative References
[DCMI-TERMS]
Initiative, D. C. M., "DCMI Metadata Terms", 2020,
<https://www.dublincore.org/specifications/dublin-core/
dcmi-terms/>.
[RFC5988] Nottingham, M., "Web Linking", RFC 5988, [RFC5988] Nottingham, M., "Web Linking", RFC 5988,
DOI 10.17487/RFC5988, October 2010, DOI 10.17487/RFC5988, October 2010,
<https://www.rfc-editor.org/info/rfc5988>. <https://www.rfc-editor.org/info/rfc5988>.
[RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
Code: The Implementation Status Section", BCP 205,
RFC 7942, DOI 10.17487/RFC7942, July 2016,
<https://www.rfc-editor.org/info/rfc7942>.
[W3C.REC-json-ld-20140116] [W3C.REC-json-ld-20140116]
Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0", Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0",
World Wide Web Consortium Recommendation REC-json-ld- World Wide Web Consortium Recommendation REC-json-ld-
20140116, January 2014, 20140116, January 2014,
<https://www.w3.org/TR/2014/REC-json-ld-20140116>. <https://www.w3.org/TR/2014/REC-json-ld-20140116>.
[W3C.REC-rdf11-concepts-20140225]
Cyganiak, R., Wood, D., and M. Lanthaler, "RDF 1.1
Concepts and Abstract Syntax", World Wide Web Consortium
Recommendation REC-rdf11-concepts-20140225, February 2014,
<https://www.w3.org/TR/2014/REC-rdf11-concepts-20140225>.
10.3. URIs 10.3. URIs
[1] https://www.w3.org/TR/2014/REC-json-ld-20140116/#interpreting- [1] https://www.w3.org/TR/2014/REC-json-ld-20140116/#interpreting-
json-as-json-ld json-as-json-ld
Appendix A. JSON-LD Context Appendix A. JSON-LD Context
A set of links rendered according to the JSON serialization defined A set of links rendered according to the JSON serialization defined
in Section 4.2 can be interpreted as RDF triples by adding a JSON-LD in Section 4.2 can be interpreted as RDF triples by adding a JSON-LD
context [W3C.REC-json-ld-20140116] that maps the JSON keys to context [W3C.REC-json-ld-20140116] that maps the JSON keys to
skipping to change at line 1304 skipping to change at page 30, line 4
{ {
"value": "Voyez-le en action!", "value": "Voyez-le en action!",
"language": "fr" "language": "fr"
} }
] ]
} }
] ]
} }
] ]
} }
Figure 13: Using a typed link to support discovery of a JSON-LD Figure 13: Using a typed link to support discovery of a JSON-LD
Context for a Set of Links Context for a Set of Links
In order to obtain the JSON-LD Context conveyed by the server, the In order to obtain the JSON-LD Context conveyed by the server, the
user agent issues an HTTP GET against the link target of the link user agent issues an HTTP GET against the link target of the link
with the "http://www.w3.org/ns/json-ld#context" relation type. The with the "http://www.w3.org/ns/json-ld#context" relation type. The
response to this GET is shown in Figure 14. This particular JSON-LD response to this GET is shown in Figure 14. This particular JSON-LD
context maps "application/linkset+json" representations of link sets context maps "application/linkset+json" representations of link sets
to Dublin Core Terms. Note that the "linkset" entry in the JSON-LD to Dublin Core Terms [DCMI-TERMS]. Note that the "linkset" entry in
context is introduced to support links with the ""linkset"" relation the JSON-LD context is introduced to support links with the
type in link sets. ""linkset"" relation type in link sets.
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Type: application/ld+json Content-Type: application/ld+json
Content-Length: 658 Content-Length: 658
{ {
"@context": [ "@context": [
{ {
"@version": 1.1, "@version": 1.1,
"@vocab": "https://gs1.org/voc/", "@vocab": "https://gs1.org/voc/",
skipping to change at line 1435 skipping to change at page 33, line 27
Figure 15: RDF serialization of the link set resulting from applying Figure 15: RDF serialization of the link set resulting from applying
the JSON-LD context the JSON-LD context
Appendix B. Implementation Status Appendix B. Implementation Status
This section is to be removed before publishing as an RFC. This section is to be removed before publishing as an RFC.
This section records the status of known implementations of the This section records the status of known implementations of the
protocol defined by this specification at the time of posting of this protocol defined by this specification at the time of posting of this
Internet-Draft, and is based on a proposal described in RFC 6982 Internet-Draft, and is based on a proposal described in RFC 7942
[RFC6982]. The description of implementations in this section is [RFC7942]. The description of implementations in this section is
intended to assist the IETF in its decision processes in progressing intended to assist the IETF in its decision processes in progressing
drafts to RFCs. Please note that the listing of any individual drafts to RFCs. Please note that the listing of any individual
implementation here does not imply endorsement by the IETF. implementation here does not imply endorsement by the IETF.
Furthermore, no effort has been spent to verify the information Furthermore, no effort has been spent to verify the information
presented here that was supplied by IETF contributors. This is not presented here that was supplied by IETF contributors. This is not
intended as, and must not be construed to be, a catalog of available intended as, and must not be construed to be, a catalog of available
implementations or their features. Readers are advised to note that implementations or their features. Readers are advised to note that
other implementations may exist. other implementations may exist.
According to RFC 6982, "this will allow reviewers and working groups According to RFC 7942, "this will allow reviewers and working groups
to assign due consideration to documents that have the benefit of to assign due consideration to documents that have the benefit of
running code, which may serve as evidence of valuable experimentation running code, which may serve as evidence of valuable experimentation
and feedback that have made the implemented protocols more mature. and feedback that have made the implemented protocols more mature.
It is up to the individual working groups to use this information as It is up to the individual working groups to use this information as
they see fit". they see fit".
B.1. GS1 B.1. GS1
GS1 is a provider of identifiers, most famously seen in EAN/UPC GS1 is a provider of identifiers, most famously seen in EAN/UPC
barcodes for retail and healthcare products, and manages an ecology barcodes for retail and healthcare products, and manages an ecology
of services and standards to leverage them at a global scale. GS1 of services and standards to leverage them at a global scale. GS1
has indicated that it will fully implement this "linkset" has indicated that it will fully implement this "linkset"
specification as a means to allow requesting and representing links specification as a means to allow requesting and representing links
pertaining to products, shipments, assets and locations. Currently, pertaining to products, shipments, assets and locations. The current
the GS1 Digital Link specification makes an informative reference to GS1 Digital Link specification makes an informative reference to
version 03 of the "linkset" I-D. GS1 expresses confidence that this version 03 of the "linkset" I-D, mentions the formal adoption of that
will become a normative reference in the next iteration of that I-D by the IETF HTTPAPI Working Group, and indicates it being on
specification. track to achieve RFC status. The GS1 Digital Link specification
adopts the JSON format specified by the I-D and mentions future plans
to also support the Link header format as well as their respective
media types, neither of which have changed since version 03.
B.2. FAIR Signposting Profile B.2. FAIR Signposting Profile
The FAIR Signposting Profile is a community specification aimed at The FAIR Signposting Profile is a community specification aimed at
improving machine navigation of scholarly objects on the web through improving machine navigation of scholarly objects on the web through
the use of typed web links pointing at e.g. web resources that are the use of typed web links pointing at e.g. web resources that are
part of a specific object, persistent identifiers for the object and part of a specific object, persistent identifiers for the object and
its authors, license information pertaining to the object. The its authors, license information pertaining to the object. The
specification encourages the use of Linksets and initial specification encourages the use of Linksets and initial
implementations are ongoing, for example, for the open source implementations are ongoing, for example, for the open source
 End of changes. 31 change blocks. 
104 lines changed or deleted 126 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/