idnits 2.17.1 draft-wilde-linkset-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 18, 2018) is 2224 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6690' is defined on line 848, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6982 (Obsoleted by RFC 7942) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Wilde 3 Internet-Draft CA Technologies 4 Intended status: Informational H. Van de Sompel 5 Expires: September 19, 2018 Los Alamos National Laboratory 6 March 18, 2018 8 Linkset: Media Types and a Link Relation Type for Link Sets 9 draft-wilde-linkset-02 11 Abstract 13 This specification defines two media types and a link relation type 14 for sets of links. The media types can be used to represents links 15 in a standalone fashion, in one case in the native format used in the 16 HTTP Link header, and in the other case in a JSON-based format. The 17 link relation can be used to reference these kind of standalone link 18 sets, so that a resource can indicate that additional links putting 19 it into context are available someplace else. One typical scenario 20 is when the number of links to put in an HTTP Link header field 21 becomes too big, and thus these links should be provided by a 22 distinct resource. 24 Note to Readers 26 Please discuss this draft on the ART mailing list 27 (). 29 Online access to all versions and files is available on GitHub 30 (). 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on September 19, 2018. 49 Copyright Notice 51 Copyright (c) 2018 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3.1. Third-Party Links . . . . . . . . . . . . . . . . . . . . 4 70 3.2. Challenges Writing to HTTP Link Header Field . . . . . . 4 71 3.3. Large Number of Links . . . . . . . . . . . . . . . . . . 5 72 4. Document Formats for Link Sets . . . . . . . . . . . . . . . 5 73 4.1. HTTP Link Document Format: application/linkset . . . . . 6 74 4.2. JSON Document Format: application/linkset+json . . . . . 6 75 4.2.1. Link Sets . . . . . . . . . . . . . . . . . . . . . . 6 76 4.2.2. Links . . . . . . . . . . . . . . . . . . . . . . . . 6 77 4.2.3. Link Target Attributes . . . . . . . . . . . . . . . 7 78 4.2.4. Extension Target Attributes . . . . . . . . . . . . . 9 79 5. The "linkset" Relation Type for Linking to Link Sets . . . . 10 80 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 11 81 6.1. Links Provided in the Header of the Link Set Resource . . 12 82 6.2. Links Provided in the Body of the Link Set Resource, 83 Link Set Serialized as application/linkset+json . . . . . 13 84 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 85 7.1. Open Journal Systems (OJS) . . . . . . . . . . . . . . . 16 86 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 87 8.1. Link Relation Type: linkset . . . . . . . . . . . . . . . 16 88 8.2. Media Type: application/linkset . . . . . . . . . . . . . 16 89 8.2.1. IANA Considerations . . . . . . . . . . . . . . . . . 16 90 8.3. Media Type: application/linkset+json . . . . . . . . . . 17 91 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 92 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 95 1. Introduction 97 Resources on the Web often convey typed Web Links [RFC8288] as a part 98 of resource representations, for example, using the element 99 for HTML representations, or the "Link" header field in HTTP response 100 headers for representations of any media type. In some cases, 101 however, providing links by value is impractical or impossible. In 102 these cases, an approach to provide links by reference (instead of by 103 value) can solve the problem. 105 To that end, this specification defines two document formats and 106 associated media types to represent a set of links. It also defines 107 the "linkset" relation type that a resource can use to support 108 discovery of another resource that conveys links in which the former 109 resource participates. 111 2. Terminology 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 This specification uses the terms "link context" and "link target" as 118 defined in [RFC8288]. (These terms respectively correspond with 119 "Context IRI" and "Target IRI" as used in RFC 8288 [RFC8288]). 120 Although defined as IRIs, in common scenarios they are also URIs. 122 Additionally, this specification uses the following terms for types 123 of resources involved in providing links by reference: 125 o A "link set resource" is a resource that conveys a set of links. 126 Section 4 defines two representations for a set of links, based on 127 the abstract link model defined in [RFC8288]. 129 o An "origin resource" is a resource that participates in one or 130 more links provided by a link set resource. An origin resource 131 can support discovery of an associated link set resource by using 132 the relation type defined in Section 5. As such, from the 133 perspective of the origin resource, the links conveyed by the link 134 set resource are provided by reference. 136 3. Scenarios 138 The following sections outline some scenarios in which it is useful 139 to have the ability to separate resources from the links that pertain 140 to them. 142 These are all scenarios in which providing links by reference is 143 advantageous or necessary. It is important to keep in mind that, 144 when providing some links by reference, some/other links can still be 145 provided by value. 147 3.1. Third-Party Links 149 In some cases, it is useful that links pertaining to an origin 150 resource are provided by a server other than the one that hosts the 151 origin resource. For example, this allows: 153 o Providing links in which the origin resource is involved not just 154 as link context but also as link target. 156 o Providing links pertaining to the origin resource that the server 157 hosting that resource is not aware of. 159 o External management of links pertaining to the origin resource in 160 a special-purpose link management service. 162 In such cases, a third-party link set resource provides links 163 pertaining to the origin resource. This link set resource may be 164 managed by the same custodian as the origin resource, or by a third 165 party. 167 In order for the server hosting the origin resource to provide an up- 168 to-date and complete set of links in which the origin resource 169 participates, the server would need to obtain the links from the link 170 set resource, and embed them in the origin resource's representations 171 prior to responding to a client. Doing so would increase latency and 172 load, which may be unnecessary if a client is not intent on consuming 173 these links. Providing links by reference, instead of by value, 174 removes the server-to-server communication and resulting overhead 175 required to obtain links. Instead, the consumer of the origin 176 resource can decide if they need the additional links as context for 177 the resource. 179 3.2. Challenges Writing to HTTP Link Header Field 181 In some cases, it is not straightforward to write links to the HTTP 182 Link header field from an application. This can, for example, be the 183 case because not all required link information is available to the 184 application or because the application does not have the capability 185 to directly write HTTP headers. In such cases, providing links by 186 reference can be a solution because a link to a link set resource 187 associated with an origin resource can typically be added by means of 188 a web server rewrite rule that leverages the resource's URI. 190 3.3. Large Number of Links 192 When conveying links in the HTTP "Link" header, it is possible for 193 the size of the HTTP response header to become unpredictable. This 194 can be the case when links are determined dynamically dependent on a 195 range of contextual factors. It is possible to statically configure 196 a web server to correctly handle large HTTP response headers by 197 specifying an upper boundary for their size. But when the number of 198 links is unpredictable, estimating a reliable upper boundary is 199 challenging. 201 HTTP [RFC7231] defines error codes related to excess communication by 202 the user agent ("413 Request Entity Too Large" and "414 Request-URI 203 Too Long"), but no specific error codes are defined to indicate that 204 response header content exceeds the upper boundary that can be 205 handled by the server, and thus it has been truncated. As a result, 206 applications take counter measures aimed at controlling the size of 207 the HTTP "Link" header, for example by limiting the links they 208 provide to those with select relation types, thereby limiting the 209 value of the HTTP "Link" header to clients. Providing links by 210 reference, instead of by value, overcomes challenges related to the 211 unpredictable nature of the extent of HTTP "Link" headers. 213 In more extreme scenarios it is conceivable that the number of links 214 pertaining to the origin resource becomes so large that the response 215 from the associated link set resource becomes too large. This could 216 be the case for highly popular origin resources, when the link set 217 includes links in which the origin resource participates as both link 218 context and link target. In such cases, the link set resource could 219 deliver responses incrementally, for example, using a paged resource 220 model that clients can consume as required. 222 4. Document Formats for Link Sets 224 Link set resources can be represented by serializations that support 225 conveying both link contexts and link targets. This section 226 specifies two document formats based on the abstract model specified 227 in Section 2 of [RFC8288] that defines a link as consisting of a 228 "link context", a "link relation type", a "link target", and optional 229 "target attributes". In those terms, a link set resource is a 230 resource that conveys a collection of one or more such links. 232 The format defined in Section 4.1 is identical to the payload of the 233 HTTP Link header as specified in [RFC8288]. The format defined in 234 Section 4.2 is based on JSON and thus does not have the character 235 encoding limitations of HTTP header fields. 237 4.1. HTTP Link Document Format: application/linkset 239 This document format is identical to the payload of the HTTP Link 240 header. It is defined in Section 3 of [RFC8288], more specifically 241 by its ABNF production rule for "Link" and subsequent ones. The 242 assigned media type for this format is "application/linkset". 244 4.2. JSON Document Format: application/linkset+json 246 This document format is based on the native Link header field 247 representation defined by [RFC8288], but uses JSON [RFC8259] as the 248 syntax to represent the information contained in the native format. 249 It is described in this section. The assigned media type for this 250 format is "application/linkset+json". 252 4.2.1. Link Sets 254 In the JSON representation of a link set: 256 o A link set MUST be represented as a JSON array. 258 o A distinct JSON object - the "link object" - in this array MUST be 259 used to represent an individual link or multiple links that have 260 the same link context and link target. (see Section 4.2.2). 262 o Implementations MUST wrap link objects in an array, even if the 263 link set contains only one link. 265 o Implementations MUST NOT include any members other than link 266 objects in the array that represents a link set. 268 4.2.2. Links 270 In the JSON representation, individual links (as well as multiple 271 links that have the same link context and link target) are 272 represented by a JSON object, the link object. A link object adheres 273 to the following rules: 275 o Each link object MUST have an "href" member with a value that 276 represents the link target. 278 o Each link object MAY have an "anchor" member with a value that 279 represents the link context. If this member is not provided, the 280 link context is the link set resource. 282 o The value of both the "href" and "anchor" members MUST be a URI- 283 reference as defined in Section 4.1 of [RFC3986]. Note that for 284 relative references, the baseURI is the URI of the link set 285 resource. 287 o Each link object MUST have a "rel" or "rev" member (with the 288 latter one deprecated) with a value that represents one or more 289 link relation types, represented as an array of strings. The 290 value of each "rel"/"rev" link relation type MUST either be a 291 registered relation type or an extension relation type (URI), as 292 described in Sections 2.1.1 and 2.1.2 of [RFC8288], respectively. 294 o Each link object MAY have additional members representing target 295 attributes (see Section 4.2.3). 297 The following example of a JSON-serialized link set represents one 298 link with the core components of a link: link context, link relation 299 type, and link target. 301 [ { "href" : "http://example.com/foo", 302 "anchor" : "http://example.net/bar", 303 "rel" : [ "next" ] } ] 305 The following example of a JSON-serialized link set represents two 306 links with the core components of a link: link context, link relation 307 type, and link target. The syntax of this example takes advantage of 308 the fact that multiple relation types can be used in one link object 309 to represent multiple links that have the same link context and link 310 target. 312 [ { "href" : "http://example.com/foo", 313 "anchor" : "http://example.net/bar", 314 "rel" : [ "next" , "http://example.net/linkrel" ] } ] 316 The previous example is equivalent to the following one, which does 317 not use the syntax shortcut and therefore represents the two links 318 individually. 320 [ { "href" : "http://example.com/foo", 321 "anchor" : "http://example.net/bar", 322 "rel" : [ "next" ] }, 323 { "href" : "http://example.com/foo", 324 "anchor" : "http://example.net/bar", 325 "rel" : [ "http://example.net/linkrel" ] } ] 327 4.2.3. Link Target Attributes 329 In many cases, a link is further qualified by target attributes, 330 either defined by the serialization of [RFC8288] or extension 331 attributes defined and used by communities. 333 4.2.3.1. JSON Representation of RFC 8288 Target Attributes 335 RFC 8288 defines the following target attributes that may be used to 336 annotate links: "hreflang", "media", "title", "title*", and "type". 337 These target attributes follow different occurrence and value 338 patterns and MUST be handled in the JSON representation as follows: 340 o "hreflang": The optional and repeatable "hreflang" target 341 attribute MUST be represented by an array (even if there only is 342 one value to be represented), and each value in that array MUST be 343 a string - representing one value of the "hreflang" target 344 attributes for a link - which follows the same model as in the 345 [RFC8288] syntax. 347 o "media": The optional and not repeatable "media" target attribute 348 MUST be represented by a "media" member in the link object, and 349 its value MUST be a string that follows the same model as in the 350 [RFC8288] syntax. 352 o "type": The optional and not repeatable "type" target attribute 353 MUST be represented by a "type" member in the link object, and its 354 value MUST be a string that follows the same model as in the 355 [RFC8288] syntax. 357 o "title": The optional and not repeatable "title" target attribute 358 MUST be represented by a "title" member in the link object, and 359 its value MUST be a string that follows the same model as in the 360 [RFC8288] syntax. 362 o "title*": The optional and not repeatable "title*" target 363 attribute is motivated by character encoding and language issues 364 and follows the model defined in [RFC8187]. The details of the 365 JSON representation that applies to title* are described in 366 Section 4.2.3.2. 368 The following example illustrates how the repeatable "hreflang" and 369 the not repeatable "type" target attributes are represented in a link 370 object. 372 [ { "href" : "http://example.com/foo", 373 "anchor" : "http://example.net/bar", 374 "rel" : [ "next" ], 375 "hreflang" : [ "en" , "de" ], 376 "type" : "text/html" } ] 378 4.2.3.2. Internationalized Target Attributes for a Link 380 In addition to the target attributes described in Section 4.2.3, 381 [RFC8288] also supports attributes that follow the content model of 382 [RFC8187]. In [RFC8288], these target attributes are recognizable by 383 the use of a trailing asterisk in the attribute name, such as 384 "title*". The content model of [RFC8187] uses a string-based 385 microsyntax that represents the character encoding, an optional 386 language tag, and the escaped attribute value encoded according to 387 the specified character encoding. 389 The JSON serialization for these attributes is as follows: 391 o Internationalized target attributes use the attribute name 392 (including the *) as their name. 394 o The character encoding information as prescribed by [RFC8187] is 395 not preserved; instead, the attribute value is represented in the 396 character encoding used for the JSON link set. 398 o The attribute value is an array that contains one or more arrays. 399 In each of these arrays, the first value is a string representing 400 the attribute value (in its unescaped version), and the optional 401 second array value is a language tag [RFC5646] associated with 402 that attribute value. 404 The following example illustrates how the "title*" target attribute 405 defined by [RFC8288] is represented in a link object. 407 [ { "href" : "http://example.com/foo", 408 "anchor" : "http://example.net/bar", 409 "rel" : [ "next" ], 410 "title*" : [ [ "nachstes Kapitel", "de" ] ] } ] 412 The above example assumes that the german title contains an umlaut 413 character (which in the native syntax would be encoded as title*=UTF- 414 8'de'n%c3%a4chstes%20Kapitel), which gets encoded in its unescaped 415 form (but not shown here due to the limitations of RFC publication) 416 in the JSON representation. Implementations MUST properly decode/ 417 encode RFC 8187 style target attributes when transcoding between the 418 native and the JSON syntax. 420 4.2.4. Extension Target Attributes 422 Extension target attributes are attributes that are not defined by 423 RFC 8288 (as listed in Section 4.2.3.1), but are nevertheless used to 424 qualify links. They can be defined by communities in any way deemed 425 necessary, and it is up to them to make sure their usage is 426 understood by target applications. However, lacking standardization, 427 there is no interoperable understanding of these extension 428 attributes. One important consequence is that their cardinality is 429 unknown to generic applications. Therefore, in the JSON 430 serialization, all extension target attributes are treated as 431 repeatable: 433 o Extension target attributes use the attribute name (including the 434 *, if applicable) as their name. 436 o The value of an extension attribute MUST be represented by an 437 array (even if there only is one value to be represented). 439 o If the extension attribute does not have a name with a trailing 440 asterisk, then each value in that array MUST be a string that 441 represents one value of the extension target attribute. 443 o If the extension attribute has a name with a trailing asterisk (it 444 follows the content model of [RFC8187]), then each value in that 445 array MUST be an array. The value of each array MUST be 446 structured as described in Section 4.2.3.2. 448 [ { "href" : "http://example.com/foo", 449 "anchor" : "http://example.net/bar", 450 "rel" : [ "next" ], 451 "foo" : [ "foovalue" ], 452 "bar" : [ "barone", "bartwo" ], 453 "baz*" : [ [ "bazvalue", "en" ] ] } ] 455 The example shows a link object with three extension target 456 attributes. Every extension target attribute is represented by an 457 array. The two first ones are regular extension target attributes, 458 with the first one ("foo") having only one value, while the second 459 one ("bar") appeared twice and thus there are two values to 460 represent. 462 The last extension target attribute ("baz" follows the naming rule of 463 RFC 8187 and therefore is encoded according to the rules described in 464 Section Section 4.2.3.2. Specifically, the array representing the 465 extension target attribute contains arrays, each of which represents 466 the value itself, and the language tag (if one is specified). 468 5. The "linkset" Relation Type for Linking to Link Sets 470 The target of a link with the "linkset" relation type - the link set 471 resource - provides a set of links, including links in which the link 472 context - the origin resource - participates. 474 A link with the "linkset" relation type MAY be provided in the header 475 and/or the body of the origin resource's representation. It may also 476 be discovered by other means, such as through client-side 477 information. 479 More than one link with a "linkset" relation type MAY be provided. 480 Multiple such links can refer to the same set of links expressed 481 using different representations, or to different sets of links 482 (potentially provided by different services). 484 The use of a link with the "linkset" relation type does not preclude 485 the provision of links with other relation types, i.e. the origin 486 resource can provide typed links other than a "linkset" link. 487 Therefore, the effective set of links pertaining to the origin 488 resource is the union of the links that the resource itself provides, 489 and of all links - provided by the link set resource - in which it 490 participates. 492 The link set resource MAY provide the links that pertain to the 493 origin resource in its HTTP response header and/or body. 495 In common scenarios (the origin resource is distinct from the link 496 set resource), it is essential for link set representations to make 497 the URI of the origin resource explicit for those links in which the 498 origin resource acts as link context. 500 A user agent that follows a "linkset" link from an origin resource 501 MUST be aware that the link set resource can provide links in which 502 the origin resource does not participate and MAY decide to ignore 503 those links. 505 There is no constraint on the target URI of a link with the "linkset" 506 relation type; designing and using these URIs is left to the 507 discretion of implementers. 509 If an origin resource provides a "linkset" link pointing at a link 510 set resource, and that link set resource provides a "linkset" link in 511 turn, then this latter link points at links pertaining to the link 512 set resource. This means that in the context of the latter link, the 513 link set resource is an origin resource. This means that linkset 514 relations are not transitive, and it is up to a client to decide 515 whether they follow "nested chains" of "linkset" links or not. 517 6. Examples 519 Sections Section 6.1 and Section 6.2 show examples whereby the link 520 set resource provides links pertaining to the origin resource, in its 521 response header and body, respectively. 523 6.1. Links Provided in the Header of the Link Set Resource 525 Figure 1 shows a client issuing an HTTP head request against origin 526 resource http://example.org/resource1. 528 HEAD /resource1 HTTP/1.1 529 Host: example.org 530 Connection: close 532 Figure 1: Client HTTP HEAD Request 534 Figure 2 shows the response to the HEAD request of Figure 1. The 535 response contains a Link header with a link that uses the "linkset" 536 relation type. It indicates that links pertaining to the origin 537 resource are provided by link set resource http://example.com/ 538 links?uri=http%3A%2F%2Fexample.org%2Fresource. 540 HTTP/1.1 200 OK 541 Date: Mon, 28 Nov 2016 14:37:51 GMT 542 Server: Apache-Coyote/1.1 543 Link: 544 ; rel="linkset" 545 ; type="text/html" 546 Content-Length: 5214 547 Content-Type: text/html;charset=utf-8 548 Connection: close 550 Figure 2: Response to HTTP HEAD on Origin Resource 552 While in this example the URI of the link set resource uses a pattern 553 that represents the URI of the origin resource, this is opaque to the 554 client, which simply follows target URI to retrieving the link set 555 resource. 557 Figure 3 shows the client issuing an HTTP GET request against the 558 link set resource provided in Figure 2. 560 GET /links?uri=http%3A%2F%2Fexample.org%2Fresource HTTP/1.1 561 Host: example.com 562 Connection: close 564 Figure 3: Client HTTP GET against the Link Set Resource 566 Figure 4 shows the response headers to the HTTP GET request of 567 Figure 3. The links pertaining to the origin resource are provided 568 in the Link response header of the link set resource. As can be 569 seen, in order to support an unambiguous determination of the link 570 context of each link, the "anchor" attribute is always provided. 571 Note that most, but not all, links have the origin resource as link 572 context (anchor). 574 HTTP/1.1 200 OK 575 Date: Mon, 28 Nov 2016 14:40:02 GMT 576 Server: Apache-Coyote/1.1 577 Link: 578 ; rel="author" 579 ; type="application/rdf+xml" 580 ; anchor="http://example.org/resource1", 581 582 ; rel="author" 583 ; type="application/rdf+xml" 584 ; anchor="http://example.org/resource1", 585 586 ; rel="item" 587 ; type="application/pdf" 588 ; anchor="http://example.org/resource1", 589 590 ; rel="item" 591 ; type="text/html" 592 ; anchor="http://example.org/resource1", 593 594 ; rel="related" 595 ; type="application/pdf" 596 ; anchor="http://example.org/resource1/items/AF48EF.pdf" 597 Content-Type: text/html 598 Content-Length: 3018 600 Figure 4: Response to HTTP GET against the Link Set Resource 602 6.2. Links Provided in the Body of the Link Set Resource, Link Set 603 Serialized as application/linkset+json 605 Figure 5 is an example of a client issuing an HTTP head request 606 against origin resource http://example.org/article?id=10.1371/ 607 journal.pone.0167475 609 HEAD article?id=10.1371/journal.pone.0167475 HTTP/1.1 610 Host: example.org 611 Connection: close 613 Figure 5: Client HTTP HEAD Request 615 Figure 6 shows the response to the HEAD request of Figure 5. The 616 response contains a Link header with a link that has the "linkset" 617 relation type. It indicates that links pertaining to the origin 618 resource are provided by link set resource 619 http://example.com/links/10.1371/journal.pone.0167475, which provides 620 a representation with media type application/linkset+json. 622 HTTP/1.1 200 OK 623 Date: Mon, 28 Nov 2016 14:37:51 GMT 624 Server: Apache-Coyote/1.1 625 Link: 626 ; rel="linkset" 627 ; type="application/linkset+json" 628 Content-Length: 236 629 Content-Type: text/html;charset=utf-8 630 Connection: close 632 Figure 6: Response to HTTP HEAD on Origin Resource 634 In this example, the URI of the linkset resource does not directly 635 represent the URI of the origin resource anymore. There still is an 636 association possible through the use of a URI pattern that is 637 includes identifying information. But as in the example above, the 638 URI of the link set resource is opaque to the client that simply 639 accesses the URI to retrieve the link set resource. 641 Figure 7 shows the client issuing an HTTP GET request against the 642 link set resource provided in Figure 6. 644 GET /links/10.1371/journal.pone.0167475 HTTP/1.1 645 Host: example.com 646 Accept: application/linkset+json 647 Connection: close 649 Figure 7: Client HTTP GET against the Link Set Resource 651 Figure 8 shows the response headers to the HTTP GET request of 652 Figure 7. The links pertaining to the origin resource are provided 653 in the response body of the link set resource and are serialized 654 according to the media type application/linkset+json. 656 HTTP/1.1 200 OK 657 Date: Mon, 28 Nov 2016 14:40:02 GMT 658 Server: Apache-Coyote/1.1 659 Content-Type: application/linkset+json 660 Content-Length: 794 662 [{"href":"http://authors.example.net/johndoe", 663 "anchor":"http://example.org/article?id=10.1371/journal.pone.0167475", 664 "rel":["author"],"type":"application/rdf+xml"}, 665 {"href":"http://authors.example.net/janedoe", 666 "anchor":"http://example.org/article?id=10.1371/journal.pone.0167475", 667 "rel":["author"],"type":"application/rdf+xml"}, 668 {"href":"http://example.org/resource1/items/AF48EF.pdf", 669 "anchor":"http://example.org/article?id=10.1371/journal.pone.0167475", 670 "rel":["item"],"type":"text/html"}, 671 {"href":"http://example.org/resource1/items/CB63DA.html", 672 "anchor":"http://example.org/article?id=10.1371/journal.pone.0167475", 673 "rel":"[item"],"type":"application/pdf"}, 674 {"href":"http://example.net/resource41/", 675 "anchor":"http://example.org/resource1/items/AF48EF.pdf", 676 "rel":["related"],"type":"application/pdf"}] 678 Figure 8: Response to HTTP GET against the Link Set Resource 680 If Figure 6 would have provided a link to a link set with media type 681 application/linkset, and if the client would have requested that link 682 set, then the body of the response would have been similar to 683 Figure 8. But it would have had application/linkset as Content-Type, 684 the payload of the HTTP Link header of Figure 4 as body, and an 685 accordingly adjusted value for Content-Length. 687 7. Implementation Status 689 Note to RFC Editor: Please remove this section before publication. 691 This section records the status of known implementations of the 692 protocol defined by this specification at the time of posting of this 693 Internet-Draft, and is based on a proposal described in RFC 6982 694 [RFC6982]. The description of implementations in this section is 695 intended to assist the IETF in its decision processes in progressing 696 drafts to RFCs. Please note that the listing of any individual 697 implementation here does not imply endorsement by the IETF. 698 Furthermore, no effort has been spent to verify the information 699 presented here that was supplied by IETF contributors. This is not 700 intended as, and must not be construed to be, a catalog of available 701 implementations or their features. Readers are advised to note that 702 other implementations may exist. 704 According to RFC 6982, "this will allow reviewers and working groups 705 to assign due consideration to documents that have the benefit of 706 running code, which may serve as evidence of valuable experimentation 707 and feedback that have made the implemented protocols more mature. 708 It is up to the individual working groups to use this information as 709 they see fit". 711 7.1. Open Journal Systems (OJS) 713 Open Journal Systems (OJS) is an open-source software for the 714 management of peer-reviewed academic journals, and is created by the 715 Public Knowledge Project (PKP), released under the GNU General Public 716 License. Open Journal Systems (OJS) is a journal management and 717 publishing system that has been developed by PKP through its 718 federally funded efforts to expand and improve access to research. 720 The OJS platform has implemented linkset support as an alternative 721 way to provide links when there are more than a configured limit 722 (they consider using about 10 as a good default, for testing purpose 723 it is currently set to 8). 725 8. IANA Considerations 727 8.1. Link Relation Type: linkset 729 The link relation type below has been registered by IANA per 730 Section 6.2.1 of Web Linking [RFC8288]: 732 Relation Name: linkset 734 Description: The Target IRI of a link with the "linkset" relation 735 type provides a set of links that pertain to the Context IRI of 736 the link. 738 Reference: [[ This document ]] 740 8.2. Media Type: application/linkset 742 8.2.1. IANA Considerations 744 The Internet media type [RFC6838] for a natively encoded link set is 745 application/linkset. 747 Type name: application 749 Subtype name: linkset 751 Required parameters: none 752 Optional parameters: none 754 Encoding considerations: ... 756 Security considerations: ... 758 Interoperability considerations: ... 760 Published specification: [[ This document ]] 762 Applications that use this media type: ... 764 Additional information: 766 Magic number(s): N/A 768 File extension(s): This media type does not propose a specific 769 extension. 771 Macintosh file type code(s): TEXT 773 Person & email address to contact for further information: Herbert 774 Van de Sompel 776 Intended usage: COMMON 778 Restrictions on usage: none 780 Author: Herbert Van de Sompel 782 Change controller: IETF 784 8.3. Media Type: application/linkset+json 786 The Internet media type [RFC6838] for a JSON-encoded link set is 787 application/linkset+json. 789 Type name: application 791 Subtype name: linkset+json 793 Required parameters: none 795 Optional parameters: none 797 Encoding considerations: ... 799 Security considerations: ... 801 Interoperability considerations: ... 803 Published specification: [[ This document ]] 805 Applications that use this media type: ... 807 Additional information: 809 Magic number(s): N/A 811 File extension(s): JSON documents often use ".json" as the file 812 extension, and this media type does not propose a specific 813 extension other than this generic one. 815 Macintosh file type code(s): TEXT 817 Person & email address to contact for further information: Herbert 818 Van de Sompel 820 Intended usage: COMMON 822 Restrictions on usage: none 824 Author: Herbert Van de Sompel 826 Change controller: IETF 828 9. Security Considerations 830 ... 832 10. Normative References 834 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 835 Requirement Levels", BCP 14, RFC 2119, 836 DOI 10.17487/RFC2119, March 1997, 837 . 839 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 840 Resource Identifier (URI): Generic Syntax", STD 66, 841 RFC 3986, DOI 10.17487/RFC3986, January 2005, 842 . 844 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 845 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 846 September 2009, . 848 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 849 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 850 . 852 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 853 Specifications and Registration Procedures", BCP 13, 854 RFC 6838, DOI 10.17487/RFC6838, January 2013, 855 . 857 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 858 Code: The Implementation Status Section", RFC 6982, 859 DOI 10.17487/RFC6982, July 2013, 860 . 862 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 863 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 864 DOI 10.17487/RFC7231, June 2014, 865 . 867 [RFC8187] Reschke, J., "Indicating Character Encoding and Language 868 for HTTP Header Field Parameters", RFC 8187, 869 DOI 10.17487/RFC8187, September 2017, 870 . 872 [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 873 Interchange Format", STD 90, RFC 8259, 874 DOI 10.17487/RFC8259, December 2017, 875 . 877 [RFC8288] Nottingham, M., "Web Linking", RFC 8288, 878 DOI 10.17487/RFC8288, October 2017, 879 . 881 [W3C.REC-html401-19991224] 882 Rivoal, F., "Media Queries", World Wide Web 883 Consortium Recommendation REC-css3-mediaqueries-20120619, 884 June 2012. 886 Authors' Addresses 888 Erik Wilde 889 CA Technologies 891 Email: erik.wilde@dret.net 892 URI: http://dret.net/netdret/ 893 Herbert Van de Sompel 894 Los Alamos National Laboratory 896 Email: herbertv@lanl.gov 897 URI: http://public.lanl.gov/herbertv/