idnits 2.17.1 draft-dunglas-vulcain-01.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 : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The abstract seems to contain references ([RFC7540], [RFC8297]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (September 12, 2020) is 1319 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 7540 (Obsoleted by RFC 9113) ** Downref: Normative reference to an Experimental RFC: RFC 8297 ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) -- Obsolete informational reference (is this intentional?): RFC 6982 (Obsoleted by RFC 7942) Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group K. Dunglas 3 Internet-Draft Les-Tilleuls.coop 4 Intended status: Standards Track September 12, 2020 5 Expires: March 16, 2021 7 The Vulcain Protocol 8 draft-dunglas-vulcain-01 10 Abstract 12 This specification defines new HTTP headers (and query parameters) 13 allowing a client to inform the server of the exact data it needs: 15 * "Preload" informs the server that relations of the main requested 16 resource will be necessary. The server can then reduce the number 17 of round-trips by sending the related resources ahead of time 18 using HTTP/2 [RFC7540] Server Push. When using Server Push isn't 19 possible (resources served by a different authority, client or 20 server not supporting HTTP/2...), the server can hint the client 21 to fetch those resources as early as possible by using the 22 "preload" link relation [W3C.CR-preload-20190626] and the "103" 23 status code [RFC8297]. 25 * "Fields" informs the server of the list of fields of the retrieved 26 resources that will be used. In order to improve performance and 27 reduce bandwidth usage, the server can omit the fields not 28 requested. 30 Status of This Memo 32 This Internet-Draft is submitted in full conformance with the 33 provisions of BCP 78 and BCP 79. 35 Internet-Drafts are working documents of the Internet Engineering 36 Task Force (IETF). Note that other groups may also distribute 37 working documents as Internet-Drafts. The list of current Internet- 38 Drafts is at https://datatracker.ietf.org/drafts/current/. 40 Internet-Drafts are draft documents valid for a maximum of six months 41 and may be updated, replaced, or obsoleted by other documents at any 42 time. It is inappropriate to use Internet-Drafts as reference 43 material or to cite them other than as "work in progress." 45 This Internet-Draft will expire on March 16, 2021. 47 Copyright Notice 49 Copyright (c) 2020 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 54 license-info) in effect on the date of publication of this document. 55 Please review these documents carefully, as they describe your rights 56 and restrictions with respect to this document. Code Components 57 extracted from this document must include Simplified BSD License text 58 as described in Section 4.e of the Trust Legal Provisions and are 59 provided without warranty as described in the Simplified BSD License. 61 Table of Contents 63 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 64 2. Preload Header . . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Preload Example . . . . . . . . . . . . . . . . . . . . . 5 66 2.2. Using Preload Link Relations . . . . . . . . . . . . . . 6 67 3. Fields Header . . . . . . . . . . . . . . . . . . . . . . . . 6 68 3.1. Fields Example . . . . . . . . . . . . . . . . . . . . . 6 69 4. Selectors . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 4.1. Extended JSON Pointer . . . . . . . . . . . . . . . . . . 9 71 5. Query Parameters . . . . . . . . . . . . . . . . . . . . . . 9 72 6. Computing Links Server-Side . . . . . . . . . . . . . . . . . 11 73 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 8. IANA considerations . . . . . . . . . . . . . . . . . . . . . 11 75 9. Implementation Status . . . . . . . . . . . . . . . . . . . . 12 76 9.1. Vulcain Gateway Server . . . . . . . . . . . . . . . . . 12 77 9.2. Helix Vulcain Filters . . . . . . . . . . . . . . . . . . 13 78 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 11. Normative References . . . . . . . . . . . . . . . . . . . . 14 80 12. Informative References . . . . . . . . . . . . . . . . . . . 15 81 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 83 1. Terminology 85 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 86 *SHOULD NOT*, RECOMMENDED, MAY, and OPTIONAL, when they appear in 87 this document, are to be interpreted as described in [RFC2119]. 89 2. Preload Header 91 Many formats including HTML [W3C.REC-html52-20171214], JSON-LD 92 [W3C.REC-json-ld-20140116], Atom [RFC4287], XML 93 [W3C.REC-xml-20081126], HAL (https://tools.ietf.org/html/draft-kelly- 94 json-hal-08) and JSON:API (https://jsonapi.org/) allow the use of Web 95 Linking [RFC5988] to represent references between resources. 97 The "Preload" HTTP header allows the client to ask the server to 98 transmit resources linked to the main resource it will need as soon 99 as possible. 101 "Preload" is a List Structured Header 102 [I-D.ietf-httpbis-header-structure]. Its values "MUST" be Strings 103 (Section 3.3.3 of [I-D.ietf-httpbis-header-structure]). Its ABNF is: 105 Preload = sf-list 106 sf-item = sf-string 108 Its values are selectors Section 4 matching links to resources that 109 "SHOULD" be preloaded. If a value is an empty String, then all links 110 of the current documents are matched. 112 The server "MUST" recursively follow links matched by the selector. 113 When a selector traverses several resources, all the traversed 114 resources "SHOULD" be sent to the client. If several links 115 referencing the same resource are selected, this resource "MUST" be 116 sent at most once. 118 The server "MAY" limit the number resources that it sends in response 119 to one request. 121 Example: 123 Preload: "/member/*/author", "/member/*/comments" 125 The following optional parameters are defined: 127 * A Parameter whose name is "rel", and whose value is a String 128 (Section 3.3.3 of [I-D.ietf-httpbis-header-structure]) or a Token 129 (Section 3.3.4 of [I-D.ietf-httpbis-header-structure]), conveying 130 the expected relation type of the selected links. 132 * A Parameter whose name is "hreflang", and whose value is a String 133 (Section 3.3.3 of [I-D.ietf-httpbis-header-structure]), conveying 134 the expected language of the selected links. 136 * A Parameter whose name is "type", and whose value is a String 137 (Section 3.3.3 of [I-D.ietf-httpbis-header-structure]), conveying 138 the expected media type of the selected links. 140 The "rel" parameter contains a relation type as defined in [RFC5988]. 141 If this parameter is provided, the server "SHOULD" preload only 142 relations matched by the provided selector and having this type. 144 The "hreflang" parameter contains a language as defined in [RFC5988]. 145 If this parameter is provided, the server "SHOULD" preload only 146 relations matched by the provided selector and in this language. 147 When possible (for instance, when doing a HTTP/2 Server Push), the 148 server "SHOULD" set the "Accept-Language" request header to this 149 value. If the "hreflang" parameter isn't provided but the server is 150 able to guess the expected language of the relation using other 151 mechanisms (such as the "hreflang" attribute defined by the Atom 152 format for the "atom:link" element, [RFC4287] Section 4.2.7.4), then 153 the "Accept-Language" request header "SHOULD" be set to the guessed 154 value. 156 The "type" parameter contains a media type as defined in [RFC5988]. 157 If this parameter is provided, the server "SHOULD" preload only 158 relations matched by the provided selector and having this media 159 type. When possible (for instance, when doing a HTTP/2 Server Push), 160 the server "SHOULD" set the "Accept" request header to this value. 161 If the "type" parameter isn't provided but the server is able to 162 guess the expected media type of the relation using other mechanisms 163 (such as the "type" attribute defined by the Atom format for the 164 "atom:link" element, [RFC4287] Section 4.2.7.3), then the "Accept" 165 request header "SHOULD" be set to the guessed value. 167 If several parameters are provided for the same selector, the server 168 "SHOULD" preload only relations matching the selector and constraints 169 hinted by the parameters. 171 Examples: 173 Preload: "/member/*/author"; hreflang="fr-FR" 174 Preload: "/member/*/author/avatar"; type="image/webp" 176 The server "SHOULD" preload all links matched by the 177 "/member/*/author" selector and having a lang of "fr-FR", as well as 178 all links matching the "/member/*/author/avatar" selector and having 179 a type of "image/webp". 181 Preload: ""; rel=author 182 Preload: ""; rel="https://example.com/custom-rel" 183 The server "SHOULD" preload all links of the requested resource 184 having the relation type "author" or "https://example.com/custom- 185 rel". 187 2.1. Preload Example 189 Considering the following resources: 191 "/books" 193 { 194 "member": [ 195 "/books/1", 196 "/books/2" 197 ] 198 } 200 "/books/1" 202 { 203 "title": "1984", 204 "author": "/authors/1" 205 } 207 "/books/2" 209 { 210 "title": "Homage to Catalonia", 211 "author": "/authors/1" 212 } 214 "/authors/1" 216 { 217 "givenName": "George", 218 "familyName": "Orwell" 219 } 221 The "Preload" HTTP header can be used to ask the server to 222 immediately push resources related to the requested one: 224 GET /books/ HTTP/2 225 Preload: "/member/*/author" 227 In addition to "/books", the server "SHOULD" use HTTP/2 Server Push 228 to push the "/books/1", "/books/2" and "/authors/1" resources. While 229 it is referenced twice, "/authors/1" "MUST" be pushed only once. 231 Server Push requests generated by the server for related resources 232 "MUST" include the remaining selector in a "Preload" HTTP header. 233 When requesting a pushed relation, the client "MUST" compute the 234 remaining selector and pass it in the "Preload" header. 236 Explicit Request: 238 GET /books/ HTTP/2 239 Preload: "/member/*/author" 241 Request to a relation generated by the server (for the push) and the 242 client: 244 GET /books/1 HTTP/2 245 Preload: "/author" 247 2.2. Using Preload Link Relations 249 Sometimes, it's not possible or beneficial to use HTTP/2 Server Push: 250 reference to a resource not served by the same authority, client or 251 server not supporting HTTP/2, client having disabled Server Push, 252 resource probably already stored in the cache of the client... To 253 hint the client to preload the resources by initiating and early 254 request, the server "CAN" add references to the resources to preload 255 using "preload" link relations [W3C.CR-preload-20190626]. 257 3. Fields Header 259 The "Fields" HTTP header allows the client to ask the server to 260 return only the specified fields of the requested resource, and of 261 the preloaded related resources. 263 The "Fields" HTTP header is a List Structured Header accepting the 264 exact same values than the "Preload" HTTP header defined in 265 Section 2. 267 The "Fields" HTTP header "MUST" contain a selector (see #Selector). 268 The server "SHOULD" return only the fields matching this selector. 270 All matched fields "MUST" be returned if they exist. Other fields of 271 the resource "MAY" be omitted. 273 3.1. Fields Example 275 Considering the following resources: 277 "/books/1" 278 { 279 "title": "1984", 280 "genre": "novel", 281 "author": "/authors/1" 282 } 284 "/authors/1" 286 { 287 "givenName": "George", 288 "familyName": "Orwell" 289 } 291 And the following HTTP request: 293 GET /books/1 HTTP/2 294 Preload: "/author" 295 Fields: "/author/familyName", "/genre" 297 The server must return a response containing the following JSON 298 document: 300 { 301 "genre": "novel", 302 "author": "/authors/1" 303 } 305 And push the following filtered "/authors/1" resource: 307 { 308 "familyName": "Orwell" 309 } 311 Server Push requests generated by the server for related resources 312 "MUST" include the remaining selector in a "Fields" HTTP header. 313 When requesting a pushed relation, the client "MUST" compute the 314 remaining selector and pass it in the "Fields" header. 316 Example: 318 Explicit Request: 320 GET /books/ HTTP/2 321 Fields: "/member/*/author" 323 Request to a relation generated by the server (for the push) and the 324 client: 326 GET /books/1 HTTP/2 327 Fields: "/author" 329 4. Selectors 331 Selectors used as value of the "Preload" and "Fields" HTTP headers 332 depend on the "Content-Type" of the requested resource. This 333 specification defines default selector formats for common content- 334 types, and a mechanism to use other selector formats. 336 The client "SHOULD" use the "Accept" HTTP header to request the 337 resource in a format compatible with selectors used in "Preload" and 338 "Fields" HTTP headers. 340 The client can use the "Prefer" HTTP header [RFC7240] with the 341 "selector" preference to ask the server to use a specific selector 342 format: 344 GET /books/1 HTTP/2 345 Accept: text/xml 346 Prefer: selector=css 347 Fields: "brand > name" 349 If no explicit preferences have been passed, the server "MUST" assume 350 that the selector format is the default corresponding to the format 351 of the resource. 353 The following table defines the default selector format for common 354 formats: 356 +========+===================================+==============+ 357 | Format | Selector format | Identifier | 358 +========+===================================+==============+ 359 | JSON | Extended JSON Pointer Section 4.1 | json-pointer | 360 +--------+-----------------------------------+--------------+ 361 | XML | XPath [W3C.REC-xpath-19991116] | xpath | 362 +--------+-----------------------------------+--------------+ 363 | HTML | CSS selectors | css | 364 | | [W3C.REC-selectors-3-20181106] | | 365 +--------+-----------------------------------+--------------+ 367 Table 1 369 The client and the server can negotiate the use of other selector 370 formats using the "Prefer" HTTP header. 372 4.1. Extended JSON Pointer 374 For JSON documents, the default selector format is JSON Pointer 375 [RFC6901]. However, JSON Pointer doesn't provide a mechanism to 376 select entire collections. 378 This specification defines an extension to the JSON Pointer format 379 allowing to select every element of a collection, the "*" character. 381 Considering the following JSON document: 383 { 384 "books": [ 385 { 386 "title": "1984", 387 "author": "George Orwell" 388 }, 389 { 390 "title": "The Handmaid's Tale", 391 "author": "Margaret Atwood" 392 } 393 ] 394 } 396 The "/books/*/author" JSON Pointer selects the "author" field of 397 every objects in the "books" array. 399 The "*" character is escaped by encoding it as the "~2" character 400 sequence. 402 By design, this selector is simple and limited. Simple selectors 403 make it easier to limit the complexity of requests executed by the 404 server. 406 5. Query Parameters 408 Another option available to clients is to utilize Request URI query- 409 string parameters to pass preload and fields selectors. 411 The "preload" and "query" parameters "MAY" be used to pass selectors 412 corresponding respectively to the "Preload" and "Fields" HTTP 413 headers. Valid values for these query parameters are exactly the 414 same than the ones defined of the "Preload" and "Fields" HTTP 415 headers. 417 In conformance with the Section 3.4 of the URI RFC [RFC3986], values 418 of query parameters "MUST" be percent-encoded. 420 For instance, the list of fields selector ""/title","/author"" and 421 the preload selector ""/author"" passed using query parameters will 422 result in the following URL: "/books/1?fields=%22%2Ftitle%22%2C%22%2F 423 author%22&preload=%22%2Fauthor%22". 425 When using query parameters, the server "MUST" pass the remaining 426 part of the selector as parameter of the generated link. 428 "Preload" and "Fields" HTTP headers aren't CORS safe-listed request- 429 headers (https://fetch.spec.whatwg.org/#cors-safelisted-request- 430 header). Query parameters, on the other hand, allow to send cross- 431 site requests that don't trigger preflight requests. Also, query 432 parameters don't require clients to compute the remaining part of the 433 selector when requesting relations. 435 However, support for query parameters can be challenging to implement 436 by servers (links contained in served documents "MUST" be modified) 437 and generate URLs that are hard to read for a human. 439 Altering the URI can also have undesirable effects. 441 For these reasons, using HTTP headers "SHOULD" be preferred. Support 442 for query parameters is "OPTIONAL". A server supporting query 443 parameters "MUST" also support the corresponding HTTP headers. 445 Example: 447 GET /books/?preload=%22%2Fmember%2F%2A%2Fauthor%22 HTTP/2 449 { 450 "member": { 451 "/books/1?preload=%22%2Fauthor%22", 452 "/books/1?preload=%22%2Fauthor%22" 453 } 454 } 456 Example using parameters: 458 GET /books/?preload=%22%2Fmember%2F%2A%22%3B%20rel%3Dauthor HTTP/2 460 { 461 "member": { 462 "/books/1?preload=%22%22%3B%20rel%3Dauthor", 463 "/books/1?preload=%22%22%3B%20rel%3Dauthor" 464 } 465 } 467 6. Computing Links Server-Side 469 While using hypermedia capabilities of the HTTP protocol through Web 470 Linking "SHOULD" always be preferred, sometimes links between 471 resources are known by the server but are not provided in the HTTP 472 response. 474 In such cases, the server can compute the link server-side in order 475 to push the related resource. Such server-side computed links "MAY" 476 be documented, for instance by providing an OpenAPI specification 477 (https://www.openapis.org/) containing Link objects 478 (http://spec.openapis.org/oas/v3.0.2#link-object). 480 Considering the following resources and assuming that the server 481 knows that the "author" field references the resources 482 "/authors/{id}" resource: 484 "/books/1" 486 { 487 "title": "1984", 488 "author": 1 489 } 491 "/authors/1" 493 { 494 "givenName": "George", 495 "familyName": "Orwell" 496 } 498 In response to this request , both "/books/1" and "/authors/1" should 499 be pushed: 501 GET /books/1 HTTP/2 502 Preload: "/author" 504 7. Security Considerations 506 Using the "Preload" header can lead to a large number of resources to 507 be generated and pushed. The server "SHOULD" limit the maximum 508 number of resources to push. The depth of the selector "SHOULD" also 509 be limited by the server. 511 8. IANA considerations 513 The "Preload"and "Fields" header fields will be added to the 514 "Permanent Message Header Field Names" registry defined in [RFC3864]. 516 A selector registry could also be added. 518 9. Implementation Status 520 [RFC Editor Note: Please remove this entire section prior to 521 publication as an RFC.] 523 This section records the status of known implementations of the 524 protocol defined by this specification at the time of posting of this 525 Internet-Draft, and is based on a proposal described in [RFC6982]. 526 The description of implementations in this section is intended to 527 assist the IETF in its decision processes in progressing drafts to 528 RFCs. Please note that the listing of any individual implementation 529 here does not imply endorsement by the IETF. Furthermore, no effort 530 has been spent to verify the information presented here that was 531 supplied by IETF contributors. This is not intended as, and must not 532 be construed to be, a catalog of available implementations or their 533 features. Readers are advised to note that other implementations may 534 exist. According to RFC 6982, "this will allow reviewers and working 535 groups to assign due consideration to documents that have the benefit 536 of running code, which may serve as evidence of valuable 537 experimentation and feedback that have made the implemented protocols 538 more mature. It is up to the individual working groups to use this 539 information as they see fit." 541 9.1. Vulcain Gateway Server 543 Organization responsible for the implementation: 545 Les-Tilleuls.coop 547 Implementation Name and Details: 549 Vulcain.rocks, available at https://vulcain.rocks 550 (https://vulcain.rocks) 552 Brief Description: 554 A gateway server allowing to add support for the Vulcain protocol to 555 any existing API. It is written in Go and is optimized for 556 performance. 558 Level of Maturity: 560 Beta. 562 Coverage: 564 All the features of the protocol as well as the extended JSON pointer 565 selector. 567 Version compatibility: 569 The implementation follows the draft version 00. 571 Licensing: 573 All code is covered under the GNU Affero Public License version 3 or 574 later. 576 Implementation Experience: 578 Used in production. 580 Contact Information: 582 Kévin Dunglas, kevin+vulcain@dunglas.fr 583 (mailto:kevin+vulcain@dunglas.fr) https://vulcain.rocks 584 (https://vulcain.rocks) 586 Interoperability: 588 Reported compatible with all major browsers and server-side tools. 590 9.2. Helix Vulcain Filters 592 Organization responsible for the implementation: 594 Adobe 596 Implementation Name and Details: 598 Helix Vulcain Filters, available at https://github.com/adobe/helix- 599 vulcain-filters (https://github.com/adobe/helix-vulcain-filters) 601 Brief Description: 603 Vulcain-like filters for OpenWhisk web actions. 605 Level of Maturity: 607 Stable. 609 Coverage: 611 HTTP headers as well as the extended JSON pointer selector. 613 Version compatibility: 615 The implementation follows the draft version 00. 617 Licensing: 619 All code is covered under the Apache License 2.0. 621 Implementation Experience: 623 Used in production. 625 Contact Information: 627 https://www.adobe.com/about-adobe/contact.html 628 (https://www.adobe.com/about-adobe/contact.html) 630 Interoperability: 632 Reported compatible with all major browsers and server-side tools. 634 10. Acknowledgements 636 The author would like to thank Evert Pot, who authored the Prefer- 637 Push Internet-Draft from which some parts of this specification is 638 inspired, and André R. who gave good design ideas. 640 11. Normative References 642 [RFC7240] Snell, J., "Prefer Header for HTTP", RFC 7240, 643 DOI 10.17487/RFC7240, June 2014, 644 . 646 [W3C.REC-selectors-3-20181106] 647 A elik, T., Etemad, E., Glazman, D., Hickson, I., Linss, 648 P., and J. Williams, "Selectors Level 3", World Wide Web 649 Consortium Recommendation REC-selectors-3-20181106, 650 November 6, 2018, 651 . 653 [RFC6901] Bryan, P., Ed., Zyp, K., and M. Nottingham, Ed., 654 "JavaScript Object Notation (JSON) Pointer", RFC 6901, 655 DOI 10.17487/RFC6901, April 2013, 656 . 658 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 659 Resource Identifier (URI): Generic Syntax", STD 66, 660 RFC 3986, DOI 10.17487/RFC3986, January 2005, 661 . 663 [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext 664 Transfer Protocol Version 2 (HTTP/2)", RFC 7540, 665 DOI 10.17487/RFC7540, May 2015, 666 . 668 [W3C.REC-xpath-19991116] 669 Clark, J. and S. DeRose, "XML Path Language (XPath) 670 Version 1.0", World Wide Web Consortium Recommendation 671 REC-xpath-19991116, November 16, 1999, 672 . 674 [RFC3864] Klyne, G., Nottingham, M., and J. Mogul, "Registration 675 Procedures for Message Header Fields", BCP 90, RFC 3864, 676 DOI 10.17487/RFC3864, September 2004, 677 . 679 [RFC8297] Oku, K., "An HTTP Status Code for Indicating Hints", 680 RFC 8297, DOI 10.17487/RFC8297, December 2017, 681 . 683 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 684 DOI 10.17487/RFC5988, October 2010, 685 . 687 [I-D.ietf-httpbis-header-structure] 688 Nottingham, M. and P. Kamp, "Structured Field Values for 689 HTTP", Work in Progress, Internet-Draft, draft-ietf- 690 httpbis-header-structure-19, June 3, 2020, 691 . 694 [W3C.CR-preload-20190626] 695 Grigorik, I. and Y. Weiss, "Preload", World Wide Web 696 Consortium CR CR-preload-20190626, June 26, 2019, 697 . 699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 700 Requirement Levels", BCP 14, RFC 2119, 701 DOI 10.17487/RFC2119, March 1997, 702 . 704 12. Informative References 706 [W3C.REC-html52-20171214] 707 Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and 708 S. Moon, "HTML 5.2", World Wide Web Consortium 709 Recommendation REC-html52-20171214, December 14, 2017, 710 . 712 [W3C.REC-xml-20081126] 713 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 714 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 715 Edition)", World Wide Web Consortium Recommendation REC- 716 xml-20081126, November 26, 2008, 717 . 719 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 720 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 721 December 2005, . 723 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 724 Code: The Implementation Status Section", RFC 6982, 725 DOI 10.17487/RFC6982, July 2013, 726 . 728 [W3C.REC-json-ld-20140116] 729 Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0", 730 World Wide Web Consortium Recommendation REC-json-ld- 731 20140116, January 16, 2014, 732 . 734 Author's Address 736 Kevin Dunglas 737 Les-Tilleuls.coop 738 82 rue Winston Churchill 739 59160 Lille 740 France 742 Email: kevin@les-tilleuls.coop