idnits 2.17.1 draft-toomim-httpbis-braid-http-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 : ---------------------------------------------------------------------------- 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 (Nov 17, 2019) is 1622 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC7230' is defined on line 713, but no explicit reference was found in the text == Unused Reference: 'RFC7231' is defined on line 715, but no explicit reference was found in the text == Unused Reference: 'RFC7233' is defined on line 717, but no explicit reference was found in the text == Unused Reference: 'RFC7234' is defined on line 719, but no explicit reference was found in the text ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7233 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7234 (Obsoleted by RFC 9111) == Outdated reference: A later version (-19) exists of draft-ietf-httpbis-header-structure-14 -- Possible downref: Non-RFC (?) normative reference: ref. 'XHR' -- Possible downref: Non-RFC (?) normative reference: ref. 'SSE' -- Possible downref: Non-RFC (?) normative reference: ref. 'REST' ** Obsolete normative reference: RFC 3501 (Obsoleted by RFC 9051) Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet-Draft M. Toomim 2 Expires: Mar 10, 2020 Invisible College 3 Intended status: Proposed Standard G. Little 4 Invisible College 5 R. Walker 6 Bard College 7 B. Bellomy 8 Invisible College 9 Nov 17, 2019 11 \=/====\\ |//===\\= /=\ =\==\|\=/== =|====\== 12 ||/ |\\ ||\ |\\ /|| \|\ |// //| \\\ 13 |\\ |// |\\ |// //| \\\ \\\ /\/ ||| 14 \=|====|= |/====/=\ /=\/====|=\ =\= \\= =/= 15 //\ /\\ //| |\\ |/| ||| \\\ ||| |// 16 ||| ||| |\\ |// |\/ \|/ /|\ |=\ |\\ 17 =\=\==/=/ ==| |\= ||= /== ===/=|=\=== |==\===// 19 Braid-HTTP: Synchronization for HTTP 20 draft-toomim-httpbis-braid-http-01 22 Abstract 24 Braid is a set of extensions that generalize HTTP from a state 25 transfer protocol into a state synchronization protocol. 27 Braid adds to HTTP: 29 1. Versioning to resources 30 2. Subscriptions to GET requests 31 3. Patches built on Range Requests 32 4. Merge-Types that specify OT or CRDT behavior 34 These extensions enable a web resource to synchronize automatically 35 across multiple clients, servers and proxies, and guarantee 36 consistency using a OT, CRDT, or other algorithm. 38 Status of this Memo 40 This Internet-Draft is submitted in full conformance with the 41 provisions of BCP 78 and BCP 79. 43 Internet-Drafts are working documents of the Internet Engineering 44 Task Force (IETF), its areas, and its working groups. Note that 45 other groups may also distribute working documents as 46 Internet-Drafts. The list of current Internet-Drafts is at 47 http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 The list of current Internet-Drafts can be accessed at 55 https://www.ietf.org/1id-abstracts.html 57 The list of Internet-Draft Shadow Directories can be accessed at 58 https://www.ietf.org/shadow.html 59 Table of Contents 61 1. Introduction ..................................................4 62 2. Versioning for Resources ......................................5 63 2.1. Comparison with ETag ........................................5 64 2.2. PUT a new version ...........................................6 65 2.3. PUT a new version as a patch ................................6 66 2.4. GET a specific version ......................................8 67 3. Subscriptions for GET .........................................9 68 3.1. Creating a Subscription ....................................11 69 3.2. Sending multiple updates per GET ...........................11 70 3.3. Continuing a Subscription ..................................12 71 3.4. Ending a Subscription ......................................12 72 3.5. Errors .....................................................12 73 4. Design Goals..................................................13 74 5. Use Cases ....................................................13 75 5.1. Dynamic Resources ..........................................13 76 5.2. Dynamic Proxies and Caches .................................14 77 5.3. A Serverless Chat Example ..................................14 78 6. Related Work .................................................15 79 6.1. Web Frameworks .............................................15 80 6.2. Existing IETF Standards ....................................16 81 7. IANA Considerations ..........................................16 82 7.1. Header Field Registration ..................................16 83 8. Security Considerations ......................................16 84 9. Conventions ..................................................16 85 10. Copyright Notice .............................................17 86 11. References ...................................................17 87 11.1. Normative References .......................................17 88 11.2. Informative References .....................................18 89 12. Acknowledgements .............................................19 90 13. Authors' Addresses ...........................................20 91 1. Introduction 93 When a client GETs a resource over HTTP, the server sends the latest 94 version, but does not send updates when the resource changes. If a 95 web programmer wants to synchronize with state as it changes, she 96 must work around HTTP. 98 The web has a long history of these workarounds. The original web 99 required users to click reload when a page changed. XMLHTTPRequest 100 [XHR] made it possible to update just part of a page, running a GET 101 request behind the scenes. However, a GET request still could not 102 push updates. To work around this, web programmers would poll the 103 resource, which was inefficient. Long-polling was invented to 104 overcome the inefficiencies, which was standardized as Server-Sent 105 Events [SSE]. Yet, SSE provides semantics of an event-stream, not an 106 update-stream, and although a programmer can encode a protocol within 107 the event stream for updating a resource, there is still no standard 108 way to express the update of a resource. 110 In practice, web programmers today often give up on using standards 111 for "data that changes", and instead send custom messages over a 112 WebSocket -- a hand-rolled synchronization protocol. Unfortunately, 113 this forfeits the benefits of HTTP and ReST, such as caching, and a 114 uniform interface [REST]. As the web becomes increasingly dynamic, 115 programmers must increasingly synchronize state, rather than simply 116 transfer it with HTTP. 118 Braid generalizes HTTP into a synchronization protocol, and ReST into 119 a synchronization architecture. It adds these features: 121 1. Versioning (Section 2) 123 Each resource has a history of changes, ordered in time. 125 2. Subscriptions (Section 3) 127 A Subscribe header can be added to GET requests, which promises 128 to push all future versions to the client, until the client says 129 forGET. 131 3. Range Patches [RANGE-PATCH] 133 Express changes to versions in patches, with a uniform format 134 based on Range Requests. 136 4. Merge Types [MERGE-TYPES] 138 If multiple clients and servers simultaneously edit the same 139 resource, they can guarantee a consistent resulting state by 140 implementing the same Merge Type. Resources specify their Merge 141 Type with a header. 143 Taken together, these features allow an arbitrary set of clients and 144 servers to make arbitrary edits to resources, under arbitrary network 145 delays and paritions, and merge all edits consistently, receiving 146 updates as soon as they reconnect. This enables caches to support 147 dynamic content, web applications to feature an offline mode, and 148 textareas to support collaborative editing. 150 2. Versioning for Resources 152 Each Braid resource has a current version, and a version history. 153 Versions are specified as a string in the [STRUCTURED-HEADERS] 154 format. Each version string must be unique, to differentiate any two 155 points in time. To specify the version of content in a request or 156 response body, a Version header MAY be included in a request for a 157 PUT, PATCH or POST, or in the response to a GET: 159 Version: "dkn7ov2vwg" 161 Every version has a set of Parents that denote the most recent parent 162 version(s) that were known at the time the version was created. The 163 full graph of parents forms a Directed Acyclic Graph (DAG), 164 representing the known partial order of all versions. A version A is 165 known to have occurred before a version B if and only if A is an 166 ancestor of B in the partial order. 168 Parents are also specified with a header in a PUT request or GET 169 response: 171 Parents: "ajtva12kid", "cmdpvkpll2" 173 The Parents header is a List of Strings, in the syntax of HTTP's 174 [STRUCTURED-HEADERS]. Each string is a version. For any two parent 175 versions A and B that are specified in a Parents header, A cannot be 176 a descendent of B or vice versa. The ordering of versions in the 177 list carries no meaning, and SHOULD be softed lexicographically. 179 If a client or server does not specify a Version for a resource it 180 transfers, the recipient MAY generate a new version ID of its own 181 choosing. If a client or server does not specify a Parents header 182 when transferring a new version, the recipient MAY presume that the 183 most recent versions it has seen are the parents of the new version. 185 2.1. Comparison with ETag 187 The Version header is similar to an ETag, but has two differences: 189 1. ETags are sensitive to Content-Encoding. If you send the same 190 version with a GZip Content-Encoding, it will have a different 191 ETag, but the same Version. 193 2. A Version marks a unique point in time -- not unique content. If 194 a resource is changed from version A to B, and then to C, such 195 that the contents at A are the same as the contents at C, then it 196 is possible versions A and C to have the same ETag, even though 197 they have different Versions. 199 2.2. PUT a new version 201 When a PUT request changes the state of a resource, it can specify 202 the new version of the resource, the parent versions that existed 203 when it was created, and the way multiple simultaneous changes should 204 be merged (the "Merge-Type"): 206 Request: 208 PUT /chat 209 Version: "ej4lhb9z78" | Version 210 Parents: "oakwn5b8qh", "uc9zwhw7mf" | 211 Content-Type: application/json | 212 Merge-Type: sync9 | 213 Content-Length: 73 | 214 | 215 [{text: "Hi, everyone!", | | Body 216 author: {type: "link", value: "/user/tommy"}}] | | 218 Response: 220 HTTP/1.1 200 OK 221 Patches: OK 223 Merge-Types are specified in [MERGE-TYPES]. The Version and Parents 224 headers are optional. If Version is omitted, the recipient may 225 invent a version ID. If Parents is omitted, the recipient may assume 226 that the current set of leaf versions on its machine is the version's 227 context. 229 This example includes the entire new value of the state, but one can 230 also send updates as patches. 232 2.3. PUT a new version as a patch 234 Not only are patches smaller, and thus more efficient; they also 235 provide useful information for merging two simultaneous edits, for 236 instance in collaborative editing. 238 One can send an update in a patch by setting the "Patches" header to 239 a number, and then set the Message body to a sequence of that many 240 patches, separated by blank lines: 242 Request: 244 PUT /chat 245 Version: "g09ur8z74r" | Version 246 Parents: "ej4lhb9z78" | 247 Content-Type: application/json | 248 Merge-Type: sync9 | 249 Patches: 2 | 250 | 251 Content-Length: 62 | | Patch 252 Content-Range: json .messages[1:1] | | 253 | | 254 [{text: "Yo!", | | 255 author: {type: "link", value: "/user/yobot"}] | | 256 | 257 Content-Length: 40 | | Patch 258 Content-Range: json .latest_change | | 259 | | 260 {"type": "date", "value": 1573952202370} | | 262 Response: 264 HTTP/1.1 200 OK 265 Patches: OK 267 In order to distinguish each patch within a Version, we need to know 268 the length of the patch. To know the length of the patch, each patch 269 must include one of the following headers: 271 Content-Length: N 272 Transfer-Encoding: chunked 274 Either of these provide a way to determine when the next message 275 starts. 277 The previous example uses the Range Patch format, which is defined in 278 [RANGE-PATCH]. However, one can use any patch format, by sending a 279 patch with a Content-Type: set to a patch format with a defined 280 behavior, such as application/json-patch+json (as specified in 281 [RFC6902]): 283 Request: 285 PUT /chat 286 Version: "up12vyc5ib" | Version 287 Parents: "2bcbi84nsp" | 288 Content-Type: application/json | 289 Merge-Type: sync9 | 290 Patches: 1 | 291 | 292 Content-Length: 326 | | Patch 293 Content-Type: application/json-patch+json | | 294 | | 295 [ | | 296 { "op": "test", "path": "/a/b/c", "value": "foo" }, | | 297 { "op": "remove", "path": "/a/b/c" }, | | 298 { "op": "add", "path": "/a/b/c", "value": [] }, | | 299 { "op": "replace", "path": "/a/b/c", "value": 42 }, | | 300 { "op": "move", "from": "/a/b", "path": "/a/d }, | | 301 { "op": "copy", "from": "/a/d/d", "path": "/a/d/e" }| | 302 ] | | 304 Response: 306 HTTP/1.1 200 OK 307 Patches: OK 308 2.4. GET a specific version 310 A server can optionally allow clients to request historical versions 311 of a resource in GET requests. To request a historical version, a 312 client includes a Version and/or Parents header in the request. 314 Request: 316 GET /chat 317 Version: "ej4lhb9z78" 319 Response: 321 HTTP/1.1 209 Subscription 322 Subscribe: keep-alive 324 Version: "ej4lhb9z78" | Version 325 Parents: "oakwn5b8qh", "uc9zwhw7mf" | 326 Content-Type: application/json | 327 Merge-Type: sync9 | 328 Content-Length: 73 | 329 | 330 [{text: "Hi, everyone!", | | Body 331 author: {type: "link", value: "/user/tommy"}}] | | 333 If a GET request contains a Version header: 335 - The Subscribe header (Section 3) MUST be absent. 337 - The server SHOULD return a single response, containing that 338 version of the resource in its body, with the Version header set 339 to the version requested by the client. 341 - If the server does not support historical versions, it MAY ignore 342 the Version header and respond as usual, but MUST NOT include the 343 Version header in its response. 345 If a GET request contains a Parents header: 347 - If the request does not also contain a Version, then the request 348 MUST also contain a Subscribe header, and the server SHOULD send 349 a set of versions connecting the Parents to the current Version, 350 and then subscribe the client to future updates. 352 - If the request also contains a Version, then the server SHOULD 353 respond with a set of versions that connect the specified Parents 354 with the specified Version, and then close the connection. 356 - If the server does not support historical versions, then it MAY 357 ignore the Parents header, but MUST NOT include the Parents 358 header in its response. 360 A server MAY refactor or rebase the version history that it provides 361 to a client, so long as it does not affect the resulting state, or 362 the result of the patch-type's merges. 364 3. Subscriptions for GET 366 If a GET request includes the Subscribe header, it will return a 367 stream of versions; a new version pushed with each change. Each 368 version can contain either the new contents in its body, or a set of 369 Patches. 371 Request: 373 GET /chat 374 Subscribe: keep-alive 376 Response: 378 HTTP/1.1 209 Subscription 379 Subscribe: keep-alive 381 Version: "ej4lhb9z78" | Version 382 Parents: "oakwn5b8qh", "uc9zwhw7mf" | 383 Content-Type: application/json | 384 Merge-Type: sync9 | 385 Content-Length: 73 | 386 | 387 [{text: "Hi, everyone!", | | Body 388 author: {type: "link", value: "/user/tommy"}}] | | 390 Version: "g09ur8z74r" | Version 391 Parents: "ej4lhb9z78" | 392 Content-Type: application/json | 393 Merge-Type: sync9 | 394 Patches: 1 | 395 | 396 Content-Length: 62 | | Patch 397 Content-Range: json .messages[1:1] | | 398 | | 399 [{text: "Yo!", | | 400 author: {type: "link", value: "/user/yobot"}] | | 402 Version: "2bcbi84nsp" | Version 403 Parents: "g09ur8z74r" | 404 Content-Type: application/json | 405 Merge-Type: sync9 | 406 Patches: 1 | 407 | 408 Content-Length: 68 | | Patch 409 Content-Range: json .messages[2:2] | | 410 | | 411 [{text: "Hi, Tommy!", | | 412 author: {type: "link", value: "/user/sal"}}] | | 413 Version: "up12vyc5ib" | Version 414 Parents: "2bcbi84nsp" | 415 Content-Type: application/json | 416 Merge-Type: sync9 | 417 Patches: 1 | 418 | 419 Content-Length: 326 | | Patch 420 Content-Type: application/json-patch+json | | 421 | | 422 [ | | 423 { "op": "test", "path": "/a/b/c", "value": "foo" }, | | 424 { "op": "remove", "path": "/a/b/c" }, | | 425 { "op": "add", "path": "/a/b/c", "value": [] }, | | 426 { "op": "replace", "path": "/a/b/c", "value": 42 }, | | 427 { "op": "move", "from": "/a/b", "path": "/a/d }, | | 428 { "op": "copy", "from": "/a/d/d", "path": "/a/d/e" }| | 429 ] | | 430 3.1. Creating a Subscription 432 The "Subscribe" header on a GET request modifies the method semantics 433 to request a subscription to future updates to the data, rather than 434 only the current version of the representation data. 436 A client MAY request a subscription by issuing a GET request 437 containing a Subscribe header: 439 Subscribe 440 or Subscribe: keep-alive 441 or Subscribe: keep-alive= 443 If a server implements Subscribe, it MUST include a Subscribe header 444 in its response. The server then SHOULD keep the connection open, 445 and send updates over it. 447 In general, a server that implements subscriptions promises to keep 448 its subscribed clients up-to-date by sending changes until the client 449 closes the subscription. A subscription is different from a GET 450 connection (e.g. a TCP connection, or HTTP/2 stream). If a client 451 requests "Subscribe: keep-alive", then the subscription will be 452 remembered even after the GET connection closes. A subscription can 453 be resumed by the client issuing another GET with a Subscribe header. 455 3.2. Sending multiple updates per GET 457 To send multiple updates, a server concatenates multiple 458 sub-responses into a single response body. Each sub-response MUST 459 contain its own headers and body. Each sub-response must have a 460 known length, which means it MUST contain one of the following 461 headers: 463 - Content-Length: N 464 - Transfer-Encoding: chunked 465 - Patches: N 467 Each sub-response MUST have both headers and a body. The body may be 468 zero-length. 470 3.3. Continuing a Subscription 472 Even if a connection closes, a subscription might still be active. 473 If a server's response headers for a connection contained: 475 Subscribe: keep-alive 476 or Subscribe: keep-alive= 478 Then the server SHOULD keep the subscription open even after the 479 connection closes. This means that the server promises to keep 480 enough history to merge with the client when the client comes back 481 online. 483 When the client reconnects, it may specify the most recent versions 484 it saw from the server using the Parents header. This tells the 485 server which versions of state to catch it up from. 487 The server can suggest how long it will wait for the client by 488 responding with Subscribe: keep-alive=. A server should 489 wait at least after a connection closes before dropping the 490 subscription, and clearing its history. 492 3.4. Ending a Subscription 494 Servers and clients MAY drop a subscription at any time, no matter 495 the value of keep-alive. A client may reconnect by issuing a new GET 496 request with a new Subscribe header. 498 If a subscription is set to keep-alive, then closing the TCP/QUIC 499 connection won't end the subscription. Thus a client needs a way to 500 explicitly end the subscription. In HTTP/1, this is by sending the 501 text "forGET\n" over the TCP connection. In HTTP/2, this is by 502 issuing a CLOSE event to the GET request's stream. Alternatively, 503 since today's web browsers do not support sending extra text after a 504 request body, the client can issue a fresh request specified as a 505 FORGET method. 507 3.5. Errors 509 If a server has dropped the history that a client requests, the 510 server can return a 410 GONE response, to tell the client "sorry, I 511 don't have the history necessary to synchronize with you." 512 4. Design Goals 514 This spec is designed to be: 516 1. Backwards-compatible with existing HTTP 518 2. Easy to implement simple synchronizers with. For instance, it 519 should be easy to write a read-only synchronizer for an 520 append-only log. 522 3. Possible to implement arbitrary synchronization algorithms. For 523 instance, these extensions support any Operational Transform or 524 CRDT algorithm. 526 5. Use Cases 528 5.1. Dynamic Resources: Animating a GIF 530 Braid allows resources to become inherently dynamic -- able to change 531 over time. You can use this to make a resource animate. 533 In this example, a server streams changes to a GIF file in a sequence 534 of patches. When the client renders the new state of the GIF after 535 each patch, a new frame of animation is displayed. 537 Request: 538 GET /animated-braid.gif 539 Subscribe 541 Response: 542 HTTP/1.1 209 Subscribe 543 Content-Type: image/gif | Version 544 Patches: 2 | 545 | 546 Content-Length: 1239 | | Patch 547 Content-Range: bytes 100-200 | | 548 | | 549 | | 550 | 551 Content-Length: 62638 | | Patch 552 Content-Range: bytes 348-887 | | 553 | | 554 | | 555 5.2. Dynamic Proxies and Caches 557 Since updates aren't pushed, today's web often uses timeouts to 558 trigger a cache becoming stale. Unfortunately, sometimes the timeout 559 is wrong, and caches become out-of-date, and we have to wait for an 560 unknown cache to timeout before we can see the new version of 561 something. As a result, programmers have learned to force-reload 562 pages habitually, and caches become less efficient than necessary. 564 A cache supporting the Braid extensions, however, will automatically 565 update whenever a change occurs. If a client starts a GET 566 Subscription with a proxy, the proxy will then start and maintain a 567 GET Subscription with the origin server. The origin server will 568 promise to send the proxy updates over its GET Subscription, and the 569 proxy will then relay these changes to all connected clients. If a 570 set of clients and servers all support Braid, they will never need to 571 Force-reloading caches for any data amongst them. 573 5.3. A Serverless Chat Example 575 A Braid web application can operate offline. A user can use the app 576 from an airplane, and their edits can synchronize when they regain 577 internet connections. Additionally, the Braid protocol can be 578 expressed over peer-to-peer transports (e.g. Braid-WebRTC) to support 579 a peer-to-peer synchronization without a server. Braid-HTTP clients 580 will be able to interoperate with Braid-WebRTC peers. For example, a 581 chat application might be served and synchronized on Braid-HTTP, 582 while also establishing redundant peer-to-peer connections on 583 Braid-WebRTC. The server could then be shut down, and users of the 584 chat app could continue to send messages to one another. 586 Imagine the server serves the current set of trusted clients' IP 587 addresses at the /peers state. Each client then subscribes to the 588 /peers state with: 590 GET /peers 591 Subscribe: keep-alive 592 ------- 593 [ {ip: '13.55.32.158', pubkey: 'x371...8382'}, 594 {ip: '244.38.55.83', pubkey: 'o2u8...2s73'}, 595 ... 596 ] 598 Each peer can then choose a set of those peers with whom to establish 599 a WebRTC connection. It will then exchange Braid messages with those 600 peers over that connection. 602 6. Related Work 604 6.1. Web Frameworks 606 Web applications typically synchronize the state of a client and 607 server with layers of models, views, and controllers in web 608 frameworks. By automating synchronization within HTTP, programmers 609 have to write fewer layers of code on top of it. 611 ====== Legacy Websites ====== ====== Braid Websites ====== 613 Today's webpages are Braid generalizes HTTP 614 generated from multiple into a standard for 615 layers of state. Each layer synchronizing state within 616 has a different API. and between websites. 618 x Non-standard state API o Standard state API 620 _Client__ 621 / \ 622 : o o o o : Webpage DOM o o o o State 623 : \| \| : \| \| 624 : x x : HTML Templates o o State 625 : /| /| : /| /| 626 : x x x x : JS Models o o o o State 627 \ | | | | / | | | | 628 | | | | | | | | 629 o o o o - http:// - o o o o - http:// - 630 / | | | | \ | | | | 631 : x x x x : Views o o o o State 632 : | \| | : | \| | 633 : x x x : Controllers o o o State 634 : \ / \| : \ / \| 635 : x x : Models o o State 636 : \ / : \ / 637 \.... x ../ Database o State 638 Server 640 Today's programmers have to Each piece of Braid state (o) 641 learn each API, and wire them has a URL; whether public or 642 together, making sure that internal. State can be a 643 changes to shared state function of other state, and 644 synchronize across all and automatically recompute 645 layers and computers. when its dependencies change. 646 Braid guarantees network 647 synchronization. 649 6.2. Existing IETF Standards 651 A number of IETF specifications already standardize aspects of 652 synchronization for specific domains. IMAP [RFC3501] provides 653 synchronization of email. WebDAV provides the synchronization of 654 "collections" [RFC6578], and has been extended specifically for 655 calendar data in CalDAV [RFC4791], and vCards in [RFC6350]. More 656 recently, JMAP [RFC8620] provides an updated method of 657 synchronization, supporting mail, calendars, and contacts. 659 7. IANA Considerations 661 7.1. Header Field Registration 663 HTTP header fields are registered within the "Message Headers" 664 registry maintained at 665 . 667 This document defines the following HTTP header fields, so their 668 associated registry entries have been updated according to the 669 permanent registrations below (see [BCP90]): 671 +---------------------+----------+--------------+-------------+ 672 | Header Field Name | Protocol | Status | Reference | 673 +---------------------+----------+--------------+-------------+ 674 | Version | http | experimental | Section 2 | 675 | Parents | http | experimental | Section 2 | 676 | Merge-Type | http | experimental | Section 2.2 | 677 | Patches | http | experimental | Section 2.3 | 678 | Subscribe | http | experimental | Section 4 | 679 +---------------------+----------+--------------+-------------+ 681 The change controller is: "IETF (iesg@ietf.org) - Internet 682 Engineering Task Force". 684 8. Security Considerations 686 XXX Todo 688 9. Conventions 690 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 691 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 692 document are to be interpreted as described in [RFC2119]. 694 10. Copyright Notice 696 Copyright (c) 2019 IETF Trust and the persons identified as the 697 document authors. All rights reserved. 699 This document is subject to BCP 78 and the IETF Trust's Legal 700 Provisions Relating to IETF Documents 701 (http://trustee.ietf.org/license-info) in effect on the date of 702 publication of this document. Please review these documents 703 carefully, as they describe your rights and restrictions with respect 704 to this document. Code Components extracted from this document must 705 include Simplified BSD License text as described in Section 4.e of 706 the Trust Legal Provisions and are provided without warranty as 707 described in the Simplified BSD License. 709 11. References 711 11.1. Normative References 713 [RFC7230] "HTTP/1.1 Message Syntax and Routing", RFC 7230. 715 [RFC7231] "HTTP/1.1 Semantics and Content", RFC 7231. 717 [RFC7233] "HTTP/1.2 Range Requests", RFC 7233. 719 [RFC7234] "HTTP/1.2 Caching", RFC 7234. 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, March 1997. 724 [MERGE-TYPES] draft-toomim-httpbis-merge-types-00 726 [RANGE-PATCH] draft-toomim-httpbis-range-patch-00 728 [STRUCTURED-HEADERS] draft-ietf-httpbis-header-structure-14 729 11.2. Informative References 731 [XHR] Van Kestern, A., Aubourg, J., Song, J., and R. M. 732 Steen, H. "XMLHttpRequest", September 2019. 733 735 [SSE] Hickson, I. "Server-Sent Events", W3C Recommendation, 736 February 2015. 737 739 [REST] Fielding, R. "Architectural Styles and the Design of 740 Network-based Software Architectures" Doctoral 741 dissertation, University of California, Irvine, 2000. 743 [RFC3501] Crispin, M., "Internet Message Access Protocol - Version 744 4rev1", RFC 3501, DOI 10.17487/RFC3501, March 2003, 745 . 747 [RFC6578] Daboo, C., Quillaud, A., "Collection Synchronization 748 for Web Distributed Authoring and Versioning (WebDAV)", 749 RFC 6578, DOI 10.17487/RFC6578, March 2012, 750 . 752 [RFC4791] Daboo, C., Desruisseaux, B., Dusseault, L., "Calendaring 753 Extensions to WebDAV (CalDAV)", RFC 4791, 754 DOI 10.17487/RFC4791, March 2007, 755 . 757 [RFC6350] Perreault, S., "vCard Format Specification", RFC 6350, 758 DOI 10.17487/RFC6350, August 2011, 759 . 761 [RFC8620] Jenkins, N., Newman, C., "The JSON Meta Application 762 Protocol (JMAP)", RFC 8620, DOI 10.17487/RFC8620, 763 July 2019, . 765 [RFC6902] Bryan, P., Nottingham, M., "Javascript Object Notation 766 (JSON) Patch", RFC 6902. 768 [BCP90] Klyne, G., Nottingham, M., and J. Mogul, "Registration 769 Procedures for Message Header Fields", BCP 90, RFC 3864, 770 September 2004. 772 12. Acknowledgements 774 In addition to the authors, this spec contains intellectual 775 contributions from the following people: 777 - Seph Gentle 778 - Mitar Milutinovic 779 - Sarah Allen 780 - Duane Johnson 781 - Travis Kriplean 782 - Marius Nita 783 - Paul Pham 784 - Morgan Dixon 785 - Karthik Palaniappan 787 We thank the following people for key feedback on previous drafts: 789 - Austin Wright 790 - Martin Thomson 791 - Eric Kinnear 792 - Olli Vanhoja 793 - Julian Reschke 795 We also thank Mark Nottingham, Fred Baker, Adam Roach, and Barry 796 Leiba for facilitating a productive environment. 798 13. Authors' Addresses 800 For more information, the authors of this document are best contacted 801 via Internet mail: 803 Michael Toomim 804 Invisible College, Berkeley 805 2053 Berkeley Way 806 Berkeley, CA 94704 808 EMail: toomim@gmail.com 809 Web: https://invisible.college/@toomim 811 Greg Little 812 Invisible College, Berkeley 813 2053 Berkeley Way 814 Berkeley, CA 94704 816 EMail: glittle@gmail.com 817 Web: https://glittle.org/ 819 Rafie Walker 820 Bard College 822 EMail: slickytail.mc@gmail.com 824 Bryn Bellomy 825 Invisible College, Berkeley 826 2053 Berkeley Way 827 Berkeley, CA 94704 829 EMail: bryn@signals.io 830 Web: https://invisible.college/@bryn