idnits 2.17.1 draft-dunglas-mercure-04.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 document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There is 1 instance of too long lines in the document, the longest one being 8 characters in excess of 72. 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 expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: An application CAN send events directly to subscribers without using an external hub server, if it is able to do so. In this case, it *MAY NOT* implement the endpoint to publish updates. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: Also, when the client is a web browser, the JWT SHOULD not be made accessible to JavaScript scripts for resilience against Cross-site Scription (XSS) attacks (https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)). It's the main reason why, when the client is a web browser, using "HttpOnly" cookies as the authorization mechanism SHOULD always be preferred. -- The document date (27 August 2019) is 1704 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: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 5988 (Obsoleted by RFC 8288) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) -- Obsolete informational reference (is this intentional?): RFC 7386 (Obsoleted by RFC 7396) Summary: 5 errors (**), 0 flaws (~~), 4 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: Informational 27 August 2019 5 Expires: 28 February 2020 7 The Mercure Protocol 8 draft-dunglas-mercure-04 10 Abstract 12 Mercure is a protocol enabling the pushing of data updates to web 13 browsers and other HTTP clients in a fast, reliable and battery- 14 efficient way. It is especially useful for publishing real-time 15 updates of resources served through web APIs to reactive web and 16 mobile apps. 18 Status of This Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at https://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 This Internet-Draft will expire on 28 February 2020. 35 Copyright Notice 37 Copyright (c) 2019 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 42 license-info) in effect on the date of publication of this document. 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. Code Components 45 extracted from this document must include Simplified BSD License text 46 as described in Section 4.e of the Trust Legal Provisions and are 47 provided without warranty as described in the Simplified BSD License. 49 Table of Contents 51 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 2 52 2. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 3 53 3. Subscriptions . . . . . . . . . . . . . . . . . . . . . . . . 4 54 4. Publication . . . . . . . . . . . . . . . . . . . . . . . . . 5 55 5. Authorization . . . . . . . . . . . . . . . . . . . . . . . . 6 56 5.1. Publishers . . . . . . . . . . . . . . . . . . . . . . . 7 57 5.2. Subscribers . . . . . . . . . . . . . . . . . . . . . . . 8 58 6. Reconnection and State Reconciliation . . . . . . . . . . . . 8 59 7. Encryption . . . . . . . . . . . . . . . . . . . . . . . . . 9 60 8. Security Considerations . . . . . . . . . . . . . . . . . . . 10 61 9. Normative References . . . . . . . . . . . . . . . . . . . . 10 62 10. Informative References . . . . . . . . . . . . . . . . . . . 11 63 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 12 65 1. Terminology 67 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 68 *SHOULD NOT*, RECOMMENDED, MAY, and OPTIONAL, when they appear in 69 this document, are to be interpreted as described in [RFC2119]. 71 * Topic: The unit to which one can subscribe to changes. The topic 72 MUST be identified by an IRI [!@RFC3987] or by a string. Using an 73 HTTPS [RFC7230] or HTTP [RFC7230] URI [RFC3986] is RECOMMENDED. 75 * Publisher: An owner of a topic. Notifies the hub when the topic 76 feed has been updated. As in almost all pubsub systems, the 77 publisher is unaware of the subscribers, if any. Other pubsub 78 systems might call the publisher the "source". Typically a 79 website or a web API, but can also be a web browser. 81 * Subscriber: A client application that subscribes to real-time 82 updates of topics. Typically a Progressive Web App or a Mobile 83 App, but can also be a server. 85 * Target: A subscriber, or a group of subscribers. A publisher is 86 able to securely dispatch updates to specific targets. The target 87 MUST be identified by an IRI [!@RFC3987] or by a string. Using an 88 HTTPS [RFC7230] or HTTP [RFC7230] URI is RECOMMENDED. 90 * Hub: A server that handles subscription requests and distributes 91 the content to subscribers when the corresponding topics have been 92 updated. Any hub MAY implement its own policies on who can use 93 it. 95 2. Discovery 97 If the publisher is a server, it SHOULD advertise the URL of one or 98 more hubs to the subscriber, allowing it to receive live updates when 99 topics are updated. If more than one hub URL is specified, it is 100 RECOMMENDED that the publisher notifies each hub, so the subscriber 101 MAY subscribe to one or more of them. 103 The publisher SHOULD include at least one Link Header [RFC5988] with 104 "rel=mercure" (a hub link header). The target URL of these links 105 MUST be a hub implementing the Mercure protocol. 107 Note: this relation type has not been registered yet [RFC5988]. In 108 the meantime, the relation type "https://git.io/mercure" MAY be used 109 instead. 111 The publisher MAY provide the following target attributes in the Link 112 Headers: 114 * "last-event-id": the globally unique identifier of the last event 115 dispatched by the publisher at the time of the generation of this 116 resource. If provided, it MUST be passed to the hub through a 117 query parameter called "Last-Event-ID" and will be used to ensure 118 that possible updates having been made during between the resource 119 generation time and the connection to the hub are not lost. See 120 section #Re-Connection-and-State-Reconciliation. If this 121 attribute is provided, the publisher MUST always set the "id" 122 parameter when sending updates to the hub. 124 * "content-type": the content type of the updates that will pushed 125 by the hub. If omitted, the subscriber MUST assume that the 126 content type will be the same as that of the original resource. 127 Setting the "content-type" attribute is especially useful to hint 128 that partial updates will be pushed, using formats such as JSON 129 Patch [RFC6902] or JSON Merge Patch [RFC7386]. 131 * "key-set=": the key(s) to decrypt updates encoded in the 132 JWKS (JSON Web Key Set) format (see the Encryption section). 134 All these attributes are optional. 136 The publisher MAY also include one Link Header [RFC5988] with 137 "rel=self" (the self link header). It SHOULD contain the canonical 138 URL for the topic to which subscribers are expected to use for 139 subscriptions. If the Link with "rel=self" is omitted, the current 140 URL of the resource MUST be used as a fallback. 142 Minimal example: 144 GET /books/foo.jsonld HTTP/1.1 145 Host: example.com 147 HTTP/1.1 200 Ok 148 Content-type: application/ld+json 149 Link: ; rel="mercure" 151 {"@id": "/books/foo.jsonld", "foo": "bar"} 153 Links embedded in HTML or XML documents (as defined in the WebSub 154 recommendation) MAY also be supported by subscribers. 156 Note: the discovery mechanism described in this section is strongly 157 inspired from the one specified in the WebSub recommendation 158 (https://www.w3.org/TR/websub/#discovery). 160 3. Subscriptions 162 The subscriber subscribes to a URL exposed by a hub to receive 163 updates from one or many topics. To subscribe to updates, the client 164 opens an HTTPS connection following the Server-Sent Events 165 specification (https://html.spec.whatwg.org/multipage/server-sent- 166 events.html) to the hub's subscription URL advertised by the 167 publisher. The "GET" HTTP method must be used. The connection 168 SHOULD use HTTP/2 to leverage mutliplexing and other advanced 169 features of this protocol. 171 The subscriber specifies the list of topics to get updates from by 172 using one or several query parameters named "topic". The value of 173 these query parameters MUST be URI templates [RFC6570]. 175 Note: a URL is also a valid URI template. 177 The protocol doesn't specify the maximum number of "topic" parameters 178 that can be sent, but the hub MAY apply an arbitrary limit. 180 The EventSource JavaScript interface 181 (https://html.spec.whatwg.org/multipage/server-sent-events.html#the- 182 eventsource-interface) MAY be used to establish the connection. Any 183 other appropriate mechanism including, but not limited to, readable 184 streams (https://developer.mozilla.org/en- 185 US/docs/Web/API/Streams_API/Using_readable_streams) and 186 XMLHttpRequest (https://developer.mozilla.org/en- 187 US/docs/Web/API/XMLHttpRequest/Using_XMLHttpRequest) (used by popular 188 polyfills) MAY also be used. 190 The hub sends updates concerning all subscribed resources matching 191 the provided URI templates and the provided targets (see section 192 #Authorization). If no targets are specified, the update is 193 dispatched to all subscribers. The hub MUST send these updates as 194 text/event-stream compliant events 195 (https://html.spec.whatwg.org/multipage/server-sent-events.html#sse- 196 processing-model). 198 The "data" property MUST contain the new version of the topic. It 199 can be the full resource, or a partial update by using formats such 200 as JSON Patch "@RFC6902" or JSON Merge Patch "@RFC7386". 202 All other properties defined in the Server-Sent Events specification 203 MAY be used and SHOULD be supported by hubs. 205 The resource SHOULD be represented in a format with hypermedia 206 capabilities such as JSON-LD [W3C.REC-json-ld-20140116], Atom 207 [RFC4287], XML [W3C.REC-xml-20081126] or HTML 208 [W3C.REC-html52-20171214]. 210 Web Linking [RFC5988] SHOULD be used to indicate the IRI of the 211 resource sent in the event. When using Atom, XML or HTML as the 212 serialization format for the resource, the document SHOULD contain a 213 "link" element with a "self" relation containing the IRI of the 214 resource. When using JSON-LD, the document SHOULD contain an "@id" 215 property containing the IRI of the resource. 217 Example: 219 // The subscriber subscribes to updates for the https://example.com/foo topic 220 // and to any topic matching https://example.com/books/{name} 221 const url = new URL('https://example.com/hub'); 222 url.searchParams.append('topic', 'https://example.com/foo'); 223 url.searchParams.append('topic', 'https://example.com/bar/{id}'); 225 const eventSource = new EventSource(url); 227 // The callback will be called every time an update is published 228 eventSource.onmessage = function ({data}) { 229 console.log(data); 230 }; 232 The hub MAY require that subscribers are authorized to receive 233 updates. 235 4. Publication 237 The publisher send updates by issuing "POST" HTTPS requests on the 238 hub URL. When it receives an update, the hub dispatches it to 239 subscribers using the established server-sent events connections. 241 An application CAN send events directly to subscribers without using 242 an external hub server, if it is able to do so. In this case, it 243 *MAY NOT* implement the endpoint to publish updates. 245 The request MUST be encoded using the "application/x-www-form- 246 urlencoded" format and contain the following data: 248 * "topic": IRIs of the updated topic. If this key is present 249 several times, the first occurrence is considered to be the 250 canonical URL of the topic, and other ones are considered to be 251 alternate URLs. The hub MUST dispatch this update to subscribers 252 that are subscribed to both canonical or alternate URLs. 254 * "data": The content of the new version of this topic. 256 * "target" (optional): Target audience of this update. This key can 257 be present several times. See section #Authorization for further 258 information. 260 * "id" (optional): The topic's revision identifier: it will be used 261 as the SSE's "id" property. If omitted, the hub MUST generate a 262 valid globally unique id. It MAY be a UUID. Even if provided, 263 the hub MAY ignore the id provided by the client and generate its 264 own id. 266 * "type" (optional): The SSE's "event" property (a specific event 267 type). 269 * "retry" (optional): The SSE's "retry" property (the reconnection 270 time). 272 In the event of success, the HTTP response's body MUST be the "id" 273 associated to this update generated by the hub and a success HTTP 274 status code MUST be returned. The publisher MUST be authorized to 275 publish updates. See section #Authorization. 277 5. Authorization 279 To ensure that they are authorized, both publishers and subscribers 280 must present a valid JWS [RFC7515] in compact serialization to the 281 hub. This JWS SHOULD be short-lived, especially if the subscriber is 282 a web browser. A different key MAY be used to sign subscribers' and 283 publishers' tokens. 285 Two mechanisms are defined to present the JWS to the hub: 287 * using an "Authorization" HTTP header 288 * using a cookie 290 If the publisher or the subscriber is not a web browser, it SHOULD 291 use an "Authorization" HTTP header. This "Authorization" header MUST 292 contain the string "Bearer" followed by the JWS. The hub will check 293 that the JWS conforms to the rules (defined later) ensuring that the 294 client is authorized to publish or subscribe to updates. 296 By the "EventSource" specification, web browsers can not set custom 297 HTTP headers for such connections, and they can only be estabilished 298 using the "GET" HTTP method. However, cookies are supported and can 299 be included even in cross-domain requests if the CORS credentials are 300 set (https://html.spec.whatwg.org/multipage/server-sent- 301 events.html#dom-eventsourceinit-withcredentials): 303 If the publisher or the subscriber is a web browser, it SHOULD send a 304 cookie called "mercureAuthorization" containing the JWS when 305 connecting to the hub. 307 Whenever possible, the "mercureAuthorization" cookie SHOULD be set 308 during the discovery to improve the overall security. See section 309 #Discovery. Consequently, if the cookie is set during the discovery, 310 both the publisher and the hub have to share the same second level 311 domain. The "Domain" attribute MAY be used to allow the publisher 312 and the hub to use different subdomains. 314 The cookie SHOULD have the "Secure", "HttpOnly" and "SameSite" 315 attributes set. The cookie's "Path" attribute SHOULD also be set to 316 the hub's URL. See section #Security-Considerations. 318 When using authorization mechanisms, the connection MUST use an 319 encryption layer such as HTTPS. 321 If both an "Authorization" HTTP header and a cookie named 322 "mercureAuthorization" are presented by the client, the cookie MUST 323 be ignored. If the client tries to execute an operation it is not 324 allowed to, a 403 HTTP status code SHOULD be returned. 326 5.1. Publishers 328 Publishers MUST be authorized to dispatch updates to the hub, and 329 MUST prove that they are allowed to send updates. 331 To be allowed to publish an update, the JWT presented by the 332 publisher MUST contain a claim called "mercure", and this claim MUST 333 contain a "publish" key. "mercure.publish" MUST contain an array of 334 targets the publisher is allowed to dispatch updates to. 336 If "mercure.publish": 338 * is not defined, then the publisher MUST NOT be authorized to 339 dispatch any update 341 * contains an empty array, then the publisher is only allowed to 342 dispatch public updates 344 * contains the reserved string "*" as an array value, then the 345 publisher is authorized to dispatch updates to all targets 347 If a topic is not public, the "POST" request sent by the publisher to 348 the hub MUST contain a list of keys named "target". Their values 349 MUST be of type "string", and it is RECOMMENDED to use valid IRIs. 350 They can be, for instance, a user ID or a list of group IDs. If an 351 update contains at least one target the publisher is not authorized 352 for, the hub MUST NOT dispatch the update (even if some targets in 353 the list are allowed) and SHOULD return a 403 HTTP status code. 355 5.2. Subscribers 357 Subscribers MAY need to be authorized to connect to the hub. To 358 receive updates destined to specific targets, they MUST be 359 authorized, and MUST prove they belong to at least one of the 360 specified targets. If the subscriber is not authorized, it MUST NOT 361 receive any update having at least one target. 363 To receive updates destined for specific targets, the JWS presented 364 by the subscriber MUST have a claim named "mercure" with a key named 365 "subscribe" that contains an array of strings: a list of targets the 366 user is authorized to receive updates for. The targets SHOULD be 367 IRIs. 369 If at least one target is specified, the update MUST NOT be sent to 370 the subscriber by the hub, unless the "mercure.subscribe" array of 371 the JWS presented by the subscriber contains at least one of the 372 specified targets. 374 If the "mercure.subscribe" array contains the reserved string value 375 "*", then the subscriber is authorized to receive updates destined 376 for all targets. 378 6. Reconnection and State Reconciliation 380 To allow re-establishment in case of connection lost, events 381 dispatched by the hub SHOULD include an "id" property. The value 382 contained in this "id" property SHOULD be a globally unique 383 identifier. To do so, a UUID [RFC4122] MAY be used. 385 According to the server-sent events specification, in case of 386 connection lost the subscriber will try to automatically re-connect. 387 During the re-connection, the subscriber MUST send the last received 388 event id in a Last-Event-ID (https://html.spec.whatwg.org/multipage/ 389 iana.html#last-event-id) HTTP header. 391 The server-sent events specification doesn't allow this HTTP header 392 to be set during the first connection (before a reconnection). In 393 order to fetch any update dispatched between the initial resource 394 generation by the publisher and the connection to the hub, the 395 subscriber MUST send the event id provided during the discovery in 396 the "last-event-id" link's attribute in a query parameter named 397 "Last-Event-ID" when connecting to the hub. 399 If both the "Last-Event-ID" HTTP header and the query parameter are 400 present, the HTTP header MUST take precedence. 402 If the "Last-Event-ID" HTTP header or query parameter exists, the hub 403 SHOULD send all events published following the one bearing this 404 identifier to the subscriber. 406 The hub MAY discard some messages for operational reasons. The 407 subscriber MUST NOT assume that no update will be lost, and MUST re- 408 fetch the original topic to ensure this (for instance, after a long 409 disconnection time). 411 The hub MAY also specify the reconnection time using the "retry" key, 412 as specified in the server-sent events format. 414 7. Encryption 416 Using HTTPS does not prevent the hub from accessing the update's 417 content. Depending of the intended privacy of information contained 418 in the update, it MAY be necessary to prevent eavesdropping by the 419 hub. 421 To make sure that the message content can not be read by the hub, the 422 publisher MAY encode the message before sending it to the hub. The 423 publisher SHOULD use JSON Web Encryption [RFC7516] to encrypt the 424 update content. The publisher MAY provide the relevant encryption 425 key(s) in the "key-set" attribute of the Link HTTP header during the 426 discovery. The "key-set" attribute SHOULD contain a key encoded 427 using the JSON Web Key Set [RFC7517] format. Any other out-of-band 428 mechanism MAY be used instead to share the key between the publisher 429 and the subscriber. 431 Update encyption is considered a best practice to prevent mass 432 surveillance. This is especially relevant if the hub is managed by 433 an external provider. 435 8. Security Considerations 437 The confidentiality of the secret key(s) used to generate the JWTs is 438 a primary concern. The secret key(s) MUST be stored securely. They 439 MUST be revoked immediately in the event of compromission. 441 Possessing valid JWTs allows any client to subscribe, or to publish 442 to the hub. Their confidentiality MUST therefore be ensured. To do 443 so, JWTs MUST only be transmitted over secure connections. 445 Also, when the client is a web browser, the JWT SHOULD not be made 446 accessible to JavaScript scripts for resilience against Cross-site 447 Scription (XSS) attacks (https://www.owasp.org/index.php/Cross- 448 site_Scripting_(XSS)). It's the main reason why, when the client is 449 a web browser, using "HttpOnly" cookies as the authorization 450 mechanism SHOULD always be preferred. 452 In the event of compromission, revoking JWTs before their expiration 453 is often difficult. To that end, using short-lived tokens is 454 strongly RECOMMENDED. 456 The publish endpoint of the hub may be targeted by Cross-Site Request 457 Forgery (CSRF) attacks (https://www.owasp.org/index.php/Cross- 458 Site_Request_Forgery_(CSRF)) when the cookie-based authorization 459 mechanism is used. Therefore, implementations supporting this 460 mechanism MUST mitigate such attacks. 462 The first prevention method to implement is to set the 463 "mercureAuthorization" cookie's "SameSite" attribute. However, some 464 web browsers still not support this attribute 465 (https://caniuse.com/#feat=same-site-cookie-attribute) and will 466 remain vulnerable. Additionally, hub implementations SHOULD use the 467 "Origin" and "Referer" HTTP headers set by web browsers to verify 468 that the source origin matches the target origin. If none of these 469 headers are available, the hub SHOULD discard the request. 471 CSRF prevention techniques, including those previously mentioned, are 472 described in depth in OWASP's Cross-Site Request Forgery (CSRF) 473 Prevention Cheat Sheet (https://www.owasp.org/index.php/Cross- 474 Site_Request_Forgery_(CSRF)_Prevention_Cheat_Sheet). 476 9. Normative References 478 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 479 Requirement Levels", BCP 14, RFC 2119, 480 DOI 10.17487/RFC2119, March 1997, 481 . 483 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 484 Resource Identifier (URI): Generic Syntax", STD 66, 485 RFC 3986, DOI 10.17487/RFC3986, January 2005, 486 . 488 [RFC4122] Leach, P., Mealling, M., and R. Salz, "A Universally 489 Unique IDentifier (UUID) URN Namespace", RFC 4122, 490 DOI 10.17487/RFC4122, July 2005, 491 . 493 [RFC5988] Nottingham, M., "Web Linking", RFC 5988, 494 DOI 10.17487/RFC5988, October 2010, 495 . 497 [RFC6570] Gregorio, J., Fielding, R., Hadley, M., Nottingham, M., 498 and D. Orchard, "URI Template", RFC 6570, 499 DOI 10.17487/RFC6570, March 2012, 500 . 502 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 503 Protocol (HTTP/1.1): Message Syntax and Routing", 504 RFC 7230, DOI 10.17487/RFC7230, June 2014, 505 . 507 [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web 508 Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 509 2015, . 511 [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", 512 RFC 7516, DOI 10.17487/RFC7516, May 2015, 513 . 515 [RFC7517] Jones, M., "JSON Web Key (JWK)", RFC 7517, 516 DOI 10.17487/RFC7517, May 2015, 517 . 519 10. Informative References 521 [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom 522 Syndication Format", RFC 4287, DOI 10.17487/RFC4287, 523 December 2005, . 525 [RFC6902] Bryan, P., Ed. and M. Nottingham, Ed., "JavaScript Object 526 Notation (JSON) Patch", RFC 6902, DOI 10.17487/RFC6902, 527 April 2013, . 529 [RFC7386] Hoffman, P. and J. Snell, "JSON Merge Patch", RFC 7386, 530 DOI 10.17487/RFC7386, October 2014, 531 . 533 [W3C.REC-html52-20171214] 534 Faulkner, S., Eicholz, A., Leithead, T., Danilo, A., and 535 S. Moon, "HTML 5.2", World Wide Web Consortium 536 Recommendation REC-html52-20171214, 14 December 2017, 537 . 539 [W3C.REC-json-ld-20140116] 540 Sporny, M., Kellogg, G., and M. Lanthaler, "JSON-LD 1.0", 541 World Wide Web Consortium Recommendation REC-json-ld- 542 20140116, 16 January 2014, 543 . 545 [W3C.REC-xml-20081126] 546 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and 547 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth 548 Edition)", World Wide Web Consortium Recommendation REC- 549 xml-20081126, 26 November 2008, 550 . 552 Author's Address 554 Les-Tilleuls.coop 555 Kevin Dunglas 556 2 rue Hegel 557 59000 Lille 558 France 560 Email: kevin@les-tilleuls.coop