idnits 2.17.1 draft-wilde-linkset-00.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 : ---------------------------------------------------------------------------- ** There are 5 instances of too long lines in the document, the longest one being 95 characters in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 2, 2017) is 2458 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC3986' is defined on line 652, but no explicit reference was found in the text == Unused Reference: 'RFC6690' is defined on line 666, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-nottingham-rfc5988bis-06 ** Obsolete normative reference: RFC 5987 (Obsoleted by RFC 8187) ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) Summary: 4 errors (**), 0 flaws (~~), 5 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: February 3, 2018 Los Alamos National Laboratory 6 August 2, 2017 8 Linkset: A Link Relation Type and Media Types for Link Sets 9 draft-wilde-linkset-00 11 Abstract 13 This specification defines a link relation type and media types for 14 working with sets of links. Using this link relation type and/or the 15 media types is useful when it becomes necessary to represent links 16 outside the context of a resource they are linking. One typical 17 example are scenarios in which the number of links to put in an HTTP 18 Link header field is too big, and thus these links should become a 19 resource of their own. 21 Note to Readers 23 Please discuss this draft on the ART mailing list 24 (). 26 Online access to all versions and files is available on GitHub 27 (). 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on February 3, 2018. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Origin Resource . . . . . . . . . . . . . . . . . . . . . 3 66 2.2. Link Set Resource . . . . . . . . . . . . . . . . . . . . 3 67 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3.1. Third-Party Links . . . . . . . . . . . . . . . . . . . . 4 69 3.2. Challenges Writing to HTTP Header Field . . . . . . . . . 5 70 3.3. Large Number of Links . . . . . . . . . . . . . . . . . . 5 71 4. The "linkset" Relation Type for Linking to Link Sets . . . . 5 72 5. Document Formats for Link Sets . . . . . . . . . . . . . . . 7 73 5.1. Native Document Format for Link Sets: application/linkset 7 74 5.2. JSON Document Format for Link Sets: 75 application/linkset+json . . . . . . . . . . . . . . . . 7 76 5.2.1. Link Value Objects . . . . . . . . . . . . . . . . . 7 77 5.2.2. Link Parameters . . . . . . . . . . . . . . . . . . . 8 78 5.2.3. Internationalized Link Parameters . . . . . . . . . . 8 79 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 9 80 6.1. Links Provided in the Header of the Link Set Resource . . 9 81 6.2. Links Provided in the Body of the Link Set Resource, 82 Link Set Serialized as application/linkset+json . . . . . 11 83 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 7.1. Link Relation Type: linkset . . . . . . . . . . . . . . . 12 85 7.2. Media Type: application/linkset . . . . . . . . . . . . . 13 86 7.2.1. IANA Considerations . . . . . . . . . . . . . . . . . 13 87 7.3. Media Type: application/linkset+json . . . . . . . . . . 14 88 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 89 9. Normative References . . . . . . . . . . . . . . . . . . . . 15 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16 92 1. Introduction 94 Resources on the Web often convey typed Web Links 95 [I-D.nottingham-rfc5988bis] as a part of resource representations, 96 for example, using the element for HTML representations, or 97 the "Link" header field in HTTP response headers for representations 98 of any media type. In some cases, however, providing links by value 99 is impractical or impossible. In these cases, an approach to provide 100 links by reference (instead of by value) can solve the problem. This 101 specification defines the "linkset" relation type that allows to link 102 resources to sets of links, thereby making it possible to represent 103 links by reference, and not by value. 105 2. Terminology 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 This section introduces two types of resources involved in providing 112 links by reference, as well as the link relation type used to 113 interlink them. 115 2.1. Origin Resource 117 An "origin resource" is a resource that makes links in which it 118 participates discoverable by providing a typed link that has a "link 119 set resource" as the target. From the perspective of the origin 120 resource, the links in the "link set resource" are therefore provided 121 by reference. 123 2.2. Link Set Resource 125 A "link set resource" is a resource - distinct from the origin 126 resource, and possibly linked to from the origin resource - that 127 provides one or more links in which the origin resource participates. 129 Because the link set resource is distinct from the origin resource, 130 links provided by the link set resource must represent both the 131 source and target of each link to allow unambiguous interpretation. 133 Link set resources can be represented in any way that allows 134 representation of links in a way that supports both source and target 135 anchors of links. Section Section 5 defines two possible 136 representations, both of which are based on the link model defined by 137 Web Linking [I-D.nottingham-rfc5988bis]. 139 3. Scenarios 141 The following sections outline some scenarios in which it is useful 142 to have the ability to separate resources and links pertaining to 143 them. 145 These are all scenarios in which providing (some) links by reference 146 is advantageous or necessary to accomplish certain goals. It is 147 important to keep in mind that even when using the pattern of "links 148 by reference", it is still possible to also provide links by value, 149 allowing resources to decide and combine which of the two patterns 150 they would like to use. 152 3.1. Third-Party Links 154 In some cases, it is useful that links pertaining to an origin 155 resource are provided by a server other than the one that hosts the 156 origin resource. For example, this allows: 158 o Providing links in which the origin resource is involved not just 159 as source but also as target. 161 o Providing links pertaining to the original resource that the 162 server hosting that resource is not aware of. 164 o External management of links pertaining to the origin resource in 165 a special-purpose link management service. 167 In such cases, a third-party link set resource provides links 168 pertaining to the origin resource. This link set resource may be 169 managed by the same custodian as the origin resource, or by a third 170 party. 172 In order for the server hosting the origin resource to provide an up- 173 to-date and complete set of links for it, it would need to obtain the 174 links from the link set resource, and embed them in the origin 175 resource's representations prior to responding to a client. Doing so 176 would increase latency and load, which may be unnecessary if a client 177 is not intent on consuming these links. Providing links by 178 reference, instead of by value, removes the server-to-server 179 communication and resulting overhead required to obtain links. 180 Instead, the consumer of the origin resource can decide if they need 181 the additional links as context for the resource. 183 3.2. Challenges Writing to HTTP Header Field 185 In some cases, it is not straightforward to write links to the HTTP 186 Link header from an application. This can, for example, be the case 187 because not all required link information is available to the 188 application or because the application does not have the capability 189 to directly write HTTP headers. In such cases, providing links by 190 reference can be a solution because a link to a link set pertaining 191 to a resource can typcially be added by means of a web server rewrite 192 rule that leverages the resource's URI. 194 3.3. Large Number of Links 196 When conveying links in the HTTP "Link" header, it is possible for 197 the size of the HTTP response header to become unpredictable. This 198 can be the case when links are determined dynamically dependent on a 199 range of contextual factors. It is possible to statically configure 200 a web server to correctly handle large HTTP response headers by 201 specifying an upper boundary for their size. But when the number of 202 links is unpredictable, estimating a reliable upper boundary is 203 challenging. 205 HTTP [RFC7231] defines error codes related to excess communication by 206 the user agent ("413 Request Entity Too Large" and "414 Request-URI 207 Too Long"), but no specific error codes are defined to indicate that 208 response header content exceeds the upper boundary that can be 209 handled by the server, and thus it has been truncated. As a result, 210 applications take counter measures aimed at controlling the size of 211 the HTTP "Link" header, for example by limiting the links they 212 provide to those with select relation types, thereby limiting the 213 value of the HTTP "Link" header to clients. Providing links by 214 reference, instead of by value, overcomes challenges related to the 215 unpredictable nature of the extent of HTTP "Link" headers. 217 In more extreme scenarios it is conceivable that the number of links 218 pertaining to the origin resource becomes so large that the response 219 from the associated link set resource becomes too large. This could 220 be the case for highly popular origin resources, when the link set 221 includes incoming links as well. In such cases, the link set 222 resource could deliver responses incrementally, for example, using a 223 paged resource model that clients can consume as required, requesting 224 links incrementally by paging through the provided link set. 226 4. The "linkset" Relation Type for Linking to Link Sets 228 A link with the "linkset" link relation type has as Context IRI the 229 IRI of an origin resource, and as Target IRI the IRI of an associated 230 link set resource. 232 A link with the "linkset" relation type MAY be provided in the header 233 and/or the body of the origin resource's representation. It may also 234 be discovered by other means, such as through client-side 235 information. 237 More than one link with a "linkset" relation type MAY be provided. 238 Multiple such links can refer to the same set of links expressed 239 using different representations, or to different link sets 240 (potentially provided by different services). 242 The use of a link with the "linkset" relation type does not preclude 243 the provision of links with other relation types, i.e. the origin 244 resource can provide typed links other than a "linkset" link. 245 Therefore, the effective set of links pertaining to the origin 246 resource is the union of the links that the resource itself provides, 247 and of all links in which it participates which are provided by the 248 link set resources linked from it via "linkset" links. 250 The link set resource MAY provide the links that pertain to the 251 origin resource in its HTTP response header and/or body: 253 o In cases where the link set resource provides these links in its 254 Link HTTP response header, the payload of that header MUST comply 255 with the syntax defined in Web Linking 256 [I-D.nottingham-rfc5988bis]. The media type of the response body 257 is not constrained. 259 o In cases where the link set resource provides these links in its 260 response body, the body SHOULD allow a client to determine the 261 source and target of each provided link. The media type of the 262 response body is otherwise not constrained. 264 There is no constraint on the Target IRI of a link with the "linkset" 265 relation type; designing and using these links is left to the 266 discretion of implementers. 268 If an origin resource provides a "linkset" link pointing at a link 269 set resource, and that link set resource provides a "linkset" link in 270 turn, then this latter link points at links pertaining to the link 271 set resource. This means that in the context of the latter link, the 272 link set resource is an origin resource. This means that linkset 273 relations are not transitive, and it is up to a client to decide 274 whether they follow "nested chains" of linkset links or not. 276 5. Document Formats for Link Sets 278 This section specifies two document formats to convey link sets, one 279 that is identical to the payload of the HTTP Link header as specified 280 in RFC 5988bis [I-D.nottingham-rfc5988bis], and the other is a JSON- 281 based format that does not have the character encoding limitations to 282 which HTTP headers are subject as per RFC 5987 [RFC5987]. 284 5.1. Native Document Format for Link Sets: application/linkset 286 This document format is identical to the payload of the HTTP Link 287 header. It is defined in Section 3 of RFC 5988bis 288 [I-D.nottingham-rfc5988bis], more specifically by its ABNF production 289 rule for "Link" and subsequent ones. The assigned media type for 290 this format is application/linkset. 292 5.2. JSON Document Format for Link Sets: application/linkset+json 294 For applications that prefer a JSON serialization of link set 295 resources, the following definition provides a JSON [RFC7159] 296 serialization which is intended to faithfully reproduce the abstract 297 model of RFC 5988bis [I-D.nottingham-rfc5988bis]. 299 In the JSON representation, a link set resource is represented by an 300 array, where each member of the array is an object, which is the JSON 301 representation of a link value. Implementations MUST always wrap 302 link value representations in an array, even if a link set contains 303 only one link value. Implementations MUST NOT include any members 304 other than link value objects in the array representing a link set. 306 5.2.1. Link Value Objects 308 A link value object represents an individual link of a link set. 309 Each link value object is represented as a JSON object and MUST have 310 an "href" member that represents the link target. The value of the 311 "href" member is a URI-Reference that conveys the target IRI. 313 [ { "href" : "http://example.com/foo" } ] 315 This minimal example of a JSON-serialized link set contains just one 316 link which only uses the link target URI in its representation. In 317 most cases, links are further qualified by link parameters, which are 318 serialized as additional members of the link value object. 320 5.2.2. Link Parameters 322 In accordance with RFC 5988bis, link parameters apply to individual 323 links, and while a number of link parameters are defined by RFC 324 5988bis, other link parameters MAY occur and implementations MUST 325 ignore the ones that they do not understand. 327 Link parameters appear as members of link value objects. Their name 328 is the name of the link parameter, and their value is the value of 329 the link parameter. 331 [ { "href" : "http://example.com/foo", 332 "rel" : "next" } ] 334 This example add a link relation type to the link, using the "rel" 335 link parameter defined by RFC 5988bis. 337 RFC 5988bis defines the link parameters "rel", "anchor", "rev", 338 "hreflang", "media", "type", "title", and "title*". For the link 339 parameters "rel", "anchor", "rev", "hreflang", "media", and "type", 340 these can appear in the JSON serialization in the same way as shown 341 in the above example, as members of link value objects that have the 342 link parameter type as their name, and its value as their value. The 343 case for "title" and "title*" is different because these have been 344 specifically introduced to deal with character encoding issues in 345 HTTP link headers, and can be encoded more effectively in JSON. 347 5.2.3. Internationalized Link Parameters 349 While most link parameters can be translated directly from their RFC 350 5988bis variants, one special case are link parameters following the 351 model of RFC 5987 [RFC5987]. These link parameters use the pattern 352 of the "title" and "title*" link parameters defined by RFC 5988bis. 353 The model defined by RFC 5987 [RFC5987] and used by "title" and 354 "title*" may be used by additional link parameters as well, which can 355 be recognized by the naming scheme of using a link parameter name and 356 its variant with a trailing asterisk. The JSON serialization model 357 described here applies to all these parameters and MUST be used for 358 the JSON representation of link sets. In other words, 359 implementations MUST NOT directly translate RFC 5987 style parameters 360 into corresponding JSON link value object members. Instead they MUST 361 map them to the JSON representation defined in this section. 363 Internationalized link parameters use the link parameter name as 364 their name, and their value is either a string representing the link 365 parameter value, or an object representing one or more language 366 tagged link parameter values. In such an object, the set of members 367 uses a language tag [RFC5646] as their names, and their values are 368 strings representing the link parameter values associated with the 369 respective language tag. 371 6. Examples 373 Sections Section 6.1 and Section 6.2 show examples whereby the link 374 set resource provides links pertaining to the origin resource, in its 375 response header and body, respectively. 377 6.1. Links Provided in the Header of the Link Set Resource 379 Figure 1 shows a client issuing an HTTP head request against origin 380 resource http://example.org/resource1. 382 HEAD /resource1 HTTP/1.1 383 Host: example.org 384 Connection: close 386 Figure 1: Client HTTP HEAD Request 388 Figure 2 shows the response to the HEAD request of Figure 1. The 389 response contains a Link header with a link that uses the "linkset" 390 relation type. It indicates that links pertaining to the origin 391 resource are provided by link set resource http://example.com/ 392 links?uri=http%3A%2F%2Fexample.org%2Fresource. 394 HTTP/1.1 200 OK 395 Date: Mon, 28 Nov 2016 14:37:51 GMT 396 Server: Apache-Coyote/1.1 397 Link: 398 ; rel="linkset" 399 ; type="text/html" 400 Content-Length: 5214 401 Content-Type: text/html;charset=utf-8 402 Connection: close 404 Figure 2: Response to HTTP HEAD on Origin Resource 406 While in this example the IRI of the linkset resource uses a pattern 407 that represents the IRI of the origin resource, this is opaque to the 408 client, which simply follows the provided linkset IRI when retrieving 409 the linkset resource. 411 Figure 3 shows the client issuing an HTTP GET request against the 412 link set resource provided in Figure 2. 414 GET /links?uri=http%3A%2F%2Fexample.org%2Fresource HTTP/1.1 415 Host: example.com 416 Connection: close 418 Figure 3: Client HTTP GET against the Link Set Resource 420 Figure 4 shows the response headers to the HTTP GET request of 421 Figure 3. The links pertaining to the origin resource are provided 422 in the Link response header of the link set resource. As can be 423 seen, in order to support an unambiguous determination of the Context 424 IRI of each link, the "anchor" attribute is provided for each link. 425 Note that most, but not all, links have the origin resource as 426 Context IRI (anchor). 428 HTTP/1.1 200 OK 429 Date: Mon, 28 Nov 2016 14:40:02 GMT 430 Server: Apache-Coyote/1.1 431 Link: 432 ; rel="author" 433 ; type="application/rdf+xml" 434 ; anchor="http://example.org/resource1", 435 436 ; rel="author" 437 ; type="application/rdf+xml" 438 ; anchor="http://example.org/resource1", 439 440 ; rel="item" 441 ; type="application/pdf" 442 ; anchor="http://example.org/resource1", 443 444 ; rel="item" 445 ; type="text/html" 446 ; anchor="http://example.org/resource1", 447 448 ; rel="related" 449 ; type="application/pdf" 450 ; anchor="http://example.org/resource1/items/AF48EF.pdf" 451 Content-Type: text/html 452 Content-Length: 3018 454 Figure 4: Response to HTTP GET against the Link Set Resource 456 6.2. Links Provided in the Body of the Link Set Resource, Link Set 457 Serialized as application/linkset+json 459 Figure 5 is an example of a client issuing an HTTP head request 460 against origin resource http://example.org/article?id=10.1371/ 461 journal.pone.0167475 463 HEAD article?id=10.1371/journal.pone.0167475 HTTP/1.1 464 Host: example.org 465 Connection: close 467 Figure 5: Client HTTP HEAD Request 469 Figure 6 shows the response to the HEAD request of Figure 5. The 470 response contains a Link header with a link that has the "linkset" 471 relation type. It indicates that links pertaining to the origin 472 resource are provided by link set resource 473 http://example.com/links/10.1371/journal.pone.0167475, which provides 474 a representation with vendor media type application/ 475 vnd.example.org.linkset+json. 477 HTTP/1.1 200 OK 478 Date: Mon, 28 Nov 2016 14:37:51 GMT 479 Server: Apache-Coyote/1.1 480 Link: 481 ; rel="linkset" 482 ; type="application/linkset+json" 483 Content-Length: 236 484 Content-Type: text/html;charset=utf-8 485 Connection: close 487 Figure 6: Response to HTTP HEAD on Origin Resource 489 In this example, the IRI of the linkset resource does not directly 490 represent the IRI of the origin resource anymore. There still is an 491 association possible through a IRI pattern that is including DOI 492 information, but as in the example above, the linkset IRI is opaque 493 to the client which simply accesses the IRI to retrieve the linkset 494 resource. 496 Figure 7 shows the client issuing an HTTP GET request against the 497 link set resource provided in Figure 6. 499 GET /links/10.1371/journal.pone.0167475 HTTP/1.1 500 Host: example.com 501 Accept: application/linkset+json 502 Connection: close 504 Figure 7: Client HTTP GET against the Link Set Resource 506 Figure 8 shows the response headers to the HTTP GET request of 507 Figure 7. The links pertaining to the origin resource are provided 508 in the response body of the link set resource and are serialized 509 according to the vendor media type application/ 510 vnd.example.org.linkset+json. 512 HTTP/1.1 200 OK 513 Date: Mon, 28 Nov 2016 14:40:02 GMT 514 Server: Apache-Coyote/1.1 515 Content-Type: application/linkset+json 516 Content-Length: 794 518 [{"href":"http://authors.example.net/johndoe","anchor":"http://example.org/article?id=10.1371/journal.pone.0167475","rel":"author","type":"application/rdf+xml"}, 519 {"href":"http://authors.example.net/janedoe","anchor":"http://example.org/article?id=10.1371/journal.pone.0167475","rel":"author","type":"application/rdf+xml"}, 520 {"href":"http://example.org/resource1/items/AF48EF.pdf","anchor":"http://example.org/article?id=10.1371/journal.pone.0167475","rel":"item","type":"text/html"}, 521 {"href":"http://example.org/resource1/items/CB63DA.html","anchor":"http://example.org/article?id=10.1371/journal.pone.0167475","rel":"item","type":"application/pdf"}, 522 {"href":"http://example.net/resource41/","anchor":"http://example.org/resource1/items/AF48EF.pdf","rel":"related","type":"application/pdf"}] 524 Figure 8: Response to HTTP GET against the Link Set Resource 526 If Figure 6 would have provided a link to a link set with media type 527 application/linkset, and if the client would have requested that link 528 set, then the body of the response would have been similar to 529 Figure 8. But it would have had application/linkset as Content-Type, 530 the payload of the HTTP Link header of Figure 4 as body, and an 531 accordingly adjusted value for Content-Length. 533 7. IANA Considerations 535 7.1. Link Relation Type: linkset 537 The link relation type below has been registered by IANA per 538 Section 6.2.1 of Web Linking [I-D.nottingham-rfc5988bis]: 540 Relation Name: linkset 542 Description: The Target IRI of a link with the "linkset" relation 543 type provides a set of links that pertain to the Context IRI of 544 the link. 546 Reference: [[ This document ]] 548 7.2. Media Type: application/linkset 550 7.2.1. IANA Considerations 552 The Internet media type [RFC6838] for a natively encoded link set is 553 application/linkset. 555 Type name: application 557 Subtype name: linkset 559 Required parameters: none 561 Optional parameters: none 563 Encoding considerations: ... 565 Security considerations: ... 567 Interoperability considerations: ... 569 Published specification: [[ This document ]] 571 Applications that use this media type: ... 573 Additional information: 575 Magic number(s): N/A 577 File extension(s): This media type does not propose a specific 578 extension. 580 Macintosh file type code(s): TEXT 582 Person & email address to contact for further information: Herbert 583 Van de Sompel 585 Intended usage: COMMON 587 Restrictions on usage: none 589 Author: Herbert Van de Sompel 591 Change controller: IETF 593 7.3. Media Type: application/linkset+json 595 The Internet media type [RFC6838] for a JSON-encoded link set is 596 application/linkset+json. 598 Type name: application 600 Subtype name: linkset+json 602 Required parameters: none 604 Optional parameters: none 606 Encoding considerations: ... 608 Security considerations: ... 610 Interoperability considerations: ... 612 Published specification: [[ This document ]] 614 Applications that use this media type: ... 616 Additional information: 618 Magic number(s): N/A 620 File extension(s): JSON documents often use ".json" as the file 621 extension, and this media type does not propose a specific 622 extension other than this generic one. 624 Macintosh file type code(s): TEXT 626 Person & email address to contact for further information: Herbert 627 Van de Sompel 629 Intended usage: COMMON 631 Restrictions on usage: none 633 Author: Herbert Van de Sompel 635 Change controller: IETF 637 8. Security Considerations 639 ... 641 9. Normative References 643 [I-D.nottingham-rfc5988bis] 644 Nottingham, M., "Web Linking", draft-nottingham- 645 rfc5988bis-06 (work in progress), June 2017. 647 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 648 Requirement Levels", BCP 14, RFC 2119, 649 DOI 10.17487/RFC2119, March 1997, 650 . 652 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 653 Resource Identifier (URI): Generic Syntax", STD 66, 654 RFC 3986, DOI 10.17487/RFC3986, January 2005, 655 . 657 [RFC5646] Phillips, A., Ed. and M. Davis, Ed., "Tags for Identifying 658 Languages", BCP 47, RFC 5646, DOI 10.17487/RFC5646, 659 September 2009, . 661 [RFC5987] Reschke, J., "Character Set and Language Encoding for 662 Hypertext Transfer Protocol (HTTP) Header Field 663 Parameters", RFC 5987, DOI 10.17487/RFC5987, August 2010, 664 . 666 [RFC6690] Shelby, Z., "Constrained RESTful Environments (CoRE) Link 667 Format", RFC 6690, DOI 10.17487/RFC6690, August 2012, 668 . 670 [RFC6838] Freed, N., Klensin, J., and T. Hansen, "Media Type 671 Specifications and Registration Procedures", BCP 13, 672 RFC 6838, DOI 10.17487/RFC6838, January 2013, 673 . 675 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 676 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 677 2014, . 679 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 680 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, 681 DOI 10.17487/RFC7231, June 2014, 682 . 684 [W3C.REC-html401-19991224] 685 Rivoal, F., "Media Queries", World Wide Web 686 Consortium Recommendation REC-css3-mediaqueries-20120619, 687 June 2012. 689 Authors' Addresses 691 Erik Wilde 692 CA Technologies 694 Email: erik.wilde@dret.net 695 URI: http://dret.net/netdret/ 697 Herbert Van de Sompel 698 Los Alamos National Laboratory 700 Email: herbertv@lanl.gov 701 URI: http://public.lanl.gov/herbertv/