idnits 2.17.1 draft-daboo-webdav-sync-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, you can and should remove the disclaimer; otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 8, 2010) is 5163 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) ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Daboo 3 Internet-Draft Apple, Inc. 4 Intended status: Standards Track A. Quillaud 5 Expires: September 9, 2010 Sun Microsystems 6 March 8, 2010 8 Collection Synchronization for WebDAV 9 draft-daboo-webdav-sync-03 11 Abstract 13 This specification defines an extension to WebDAV that allows 14 efficient synchronization of the contents of a WebDAV collection. 16 Editorial Note (To be removed by RFC Editor before publication) 18 Please send comments to the Distributed Authoring and Versioning 19 (WebDAV) working group at , which may be 20 joined by sending a message with subject "subscribe" to 21 . Discussions of the WEBDAV 22 working group are archived at 23 . 25 Status of This Memo 27 This Internet-Draft is submitted to IETF in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF), its areas, and its working groups. Note that 32 other groups may also distribute working documents as Internet- 33 Drafts. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt. 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 This Internet-Draft will expire on September 9, 2010. 48 Copyright Notice 49 Copyright (c) 2010 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 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the BSD License. 62 This document may contain material from IETF Documents or IETF 63 Contributions published or made publicly available before November 64 10, 2008. The person(s) controlling the copyright in some of this 65 material may not have granted the IETF Trust the right to allow 66 modifications of such material outside the IETF Standards Process. 67 Without obtaining an adequate license from the person(s) controlling 68 the copyright in such materials, this document may not be modified 69 outside the IETF Standards Process, and derivative works of it may 70 not be created outside the IETF Standards Process, except to format 71 it for publication as an RFC or to translate it into languages other 72 than English. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 77 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 78 3. WebDAV Synchronization . . . . . . . . . . . . . . . . . . . . 5 79 3.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 5 80 3.2. DAV:sync-collection Report . . . . . . . . . . . . . . . . 6 81 3.3. Types of Changes Reported on Initial Synchronization . . . 7 82 3.4. Types of Changes Reported on Subsequent 83 Synchronizations . . . . . . . . . . . . . . . . . . . . . 7 84 3.4.1. Changed Resource . . . . . . . . . . . . . . . . . . . 8 85 3.4.2. Removed Resource . . . . . . . . . . . . . . . . . . . 8 86 3.5. Truncation of Results . . . . . . . . . . . . . . . . . . 8 87 3.6. Limiting Results . . . . . . . . . . . . . . . . . . . . . 9 88 3.7. Example: Initial DAV:sync-collection Report . . . . . . . 9 89 3.8. Example: DAV:sync-collection Report with Token . . . . . . 11 90 3.9. Example: Initial DAV:sync-collection Report with 91 Truncation . . . . . . . . . . . . . . . . . . . . . . . . 14 92 3.10. Example: Initial DAV:sync-collection Report with Limit . . 15 93 3.11. Example: DAV:sync-collection Report with Unsupported 94 Limit . . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 4. DAV:sync-token Property . . . . . . . . . . . . . . . . . . . 17 96 5. XML Element Definitions . . . . . . . . . . . . . . . . . . . 18 97 5.1. DAV:sync-collection XML Element . . . . . . . . . . . . . 18 98 5.2. DAV:sync-token XML Element . . . . . . . . . . . . . . . . 19 99 5.3. DAV:multistatus XML Element . . . . . . . . . . . . . . . 19 100 6. Security Considerations . . . . . . . . . . . . . . . . . . . 19 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 102 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 20 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 20 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 106 Appendix A. Change History (to be removed prior to 107 publication as an RFC) . . . . . . . . . . . . . . . 21 109 1. Introduction 111 WebDAV [RFC4918] defines the concept of 'collections' which are 112 hierarchical groupings of WebDAV resources on an HTTP [RFC2616] 113 server. Collections can be of arbitrary size and depth (i.e., 114 collections within collections). WebDAV clients that cache resource 115 content need a way to synchronize that data with the server (i.e., 116 detect what has changed and update their cache). This can currently 117 be done using a WebDAV PROPFIND request on a collection to list all 118 members of a collection along with their DAV:getetag property values, 119 which allows the client to determine which resources were changed, 120 added or deleted. However, this does not scale well to large 121 collections as the XML response to the PROPFIND request will grow 122 with the collection size. 124 This specification defines a new WebDAV report that results in the 125 server returning to the client only information about those resources 126 which have changed, are new or were deleted since a previous 127 execution of the report on the collection. 129 Additionally, a new property is added to collection resources that is 130 used to convey a "synchronization token" that is guaranteed to change 131 when resources within the collection have changed. 133 2. Conventions Used in This Document 135 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 136 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 137 document are to be interpreted as described in [RFC2119]. 139 This document uses XML DTD fragments ([W3C.REC-xml-20081126], Section 140 3.2) as a purely notational convention. WebDAV request and response 141 bodies cannot be validated by a DTD due to the specific extensibility 142 rules defined in Section 17 of [RFC4918] and due to the fact that all 143 XML elements defined by this specification use the XML namespace name 144 "DAV:". In particular: 146 1. element names use the "DAV:" namespace, 148 2. element ordering is irrelevant unless explicitly stated, 150 3. extension elements (elements not already defined as valid child 151 elements) may be added anywhere, except when explicitly stated 152 otherwise, 154 4. extension attributes (attributes not already defined as valid for 155 this element) may be added anywhere, except when explicitly 156 stated otherwise. 158 When an XML element type in the "DAV:" namespace is referenced in 159 this document outside of the context of an XML fragment, the string 160 "DAV:" will be prefixed to the element type. 162 This document inherits, and sometimes extends, DTD productions from 163 Section 14 of [RFC4918]. 165 3. WebDAV Synchronization 167 3.1. Overview 169 One way to synchronize data between two entities is to use some form 170 of synchronization token. The token defines the state of the data 171 being synchronized at a particular point in time. It can then be 172 used to determine what has changed since one point in time and 173 another. 175 This specification defines a new WebDAV report that is used to enable 176 client-server collection synchronization based on such a token. 178 In order to synchronize the contents of a collection between a server 179 and client, the server provides the client with a synchronization 180 token each time the synchronization report is executed. That token 181 represents the state of the data being synchronized at that point in 182 time. The client can then present that same token back to the server 183 at some later time and the server will return only those items that 184 are new, have changed or were deleted since that token was generated. 185 The server also returns a new token representing the new state at the 186 time the report was run. 188 Typically the first time a client connects to the server it will need 189 to be informed of the entire state of the collection (i.e., a full 190 list of all resources that are currently contained in the 191 collection). That is done by the client sending an empty token value 192 to the server. This indicates to the server that a full listing is 193 required. 195 As an alternative, the client may choose to do its first 196 synchronization using some other mechanism on the collection (e.g. 197 some other form of batch resource information retrieval such as 198 PROPFIND, SEARCH [RFC5323], or specialized REPORTs such as those 199 defined in CalDAV [RFC4791] and CardDAV [I-D.ietf-vcarddav-carddav]) 200 and ask for the DAV:sync-token property to be returned. This 201 property (defined in Section 4) contains the same token that can be 202 used later on to issue a DAV:sync-collection report. 204 In some cases a server may only wish to maintain a limited amount of 205 history about changes to a collection. In that situation it will 206 return an error to the client when the client presents a token that 207 is "out of date". At that point the client has to fall back to 208 synchronizing the entire collection by re-running the report request 209 using an empty token value. 211 3.2. DAV:sync-collection Report 213 This specification defines the DAV:sync-collection report. 215 If this report is implemented by a WebDAV server, then the server 216 MUST list the report in the "DAV:supported-report-set" property on 217 any collection supporting synchronization. 219 To implement the behavior for this report a server needs to keep 220 track of changes to any resources in a collection. This includes 221 noting the addition of new resources, changes to existing resources 222 and removal of resources. Only internal members of the collection 223 (as defined in [RFC4918]) are to be considered. The server will 224 track each change and provide a synchronization "token" to the client 225 that describes the state of the server at a specific point in time. 226 This "token" is returned as part of the response to the "sync- 227 collection" report. Clients include the last token they got from the 228 server in the next "sync-collection" report that they execute and the 229 server provides the changes from the previous state, represented by 230 the token, to the current state, represented by the new token 231 returned. 233 The synchronization token itself is an "opaque" string - i.e., the 234 actual string data has no specific meaning or syntax. A simple 235 implementation of such a token would be a numeric counter that counts 236 each change as it occurs and relates that change to the specific 237 object that changed. 239 Marshalling: 241 The request URI MUST identify a collection. The request body MUST 242 be a DAV:sync-collection XML element (see Section 5.1), which MUST 243 contain one DAV:sync-token XML element, and one DAV:prop XML 244 element. 246 The request MUST include a Depth header with a value of "1". 248 The response body for a successful request MUST be a DAV: 249 multistatus XML element, which MUST contain one DAV:sync-token 250 element in addition to one DAV:response element for each resource 251 that was created, has changed or been deleted since the last 252 synchronization operation as specified by the DAV:sync-token 253 provided in the request. A given resource MUST appear only once 254 in the response. 256 The content of each DAV:response element differs depending on how 257 the resource was altered: 259 For resources that have changed (i.e. are new or have been 260 modified) the DAV:response MUST contain at least one DAV: 261 propstat element and MUST NOT contain any DAV:status element. 263 For resources that have been removed, the DAV:response MUST 264 contain one DAV:status with a value set to '404 Not Found' and 265 MUST NOT contain any DAV:propstat element. 267 The conditions under which each type of change may occur is 268 further described in Section 3.4. 270 Preconditions: 272 (DAV:valid-sync-token): The DAV:sync-token element value MUST map 273 to a valid token previously returned by the server. A token may 274 become invalid as the result of being "out of date" (out of the 275 range of change history maintained by the server), or for other 276 reasons (e.g. collection deleted, then recreated, ACL changes, 277 etc...). 279 Postconditions: 281 (DAV:number-of-matches-within-limits): The number of changes 282 reported in the response must fall within the client specified 283 limit. This condition might be triggered if a client requests a 284 limit on the number of responses (as per Section 3.6) but the 285 server is unable to truncate the result set at or below that 286 limit. 288 3.3. Types of Changes Reported on Initial Synchronization 290 When the DAV:sync-collection request does not contain a sync-token, 291 the server MUST return all internal members of the collection and it 292 MUST NOT return any removed resource. 294 3.4. Types of Changes Reported on Subsequent Synchronizations 296 When the DAV:sync-collection request contains a valid sync-token, two 297 types of resource state changes can be returned (changed or removed). 298 This section defines what triggers each of these to be returned. It 299 also clarifies the case where a resource may have undergone multiple 300 changes in between two synchronizations. 302 3.4.1. Changed Resource 304 A resource MUST be reported as changed if it has been mapped directly 305 under the target collection since the request sync token was 306 generated. This includes resources that have been mapped as the 307 result of a COPY, MOVE or BIND ([I-D.ietf-webdav-bind]) operation. 308 This also includes collection resources that have been created. 310 In the case where a mapping between a resource and the target 311 collection was removed, then a new mapping with the same URI created, 312 the new resource MUST be reported as changed while the old resource 313 MUST NOT be reported as removed. For example, if a resource was 314 deleted, then recreated using the same URI, it should be reported as 315 a changed resource only. 317 A resource MUST be reported as changed if its entity tag value 318 (defined in [RFC2616]) has changed since the request sync token was 319 generated. 321 A resource MAY be reported as changed if the user issuing the request 322 was granted access to this resource, due to access control changes. 324 Collection resources MUST NOT be returned as changed, except in the 325 case stated above. Instead clients are expected to synchronize 326 changes in child collection resources on an individual basis. 328 3.4.2. Removed Resource 330 A resource MUST be reported as removed if its mapping under the 331 target collection has been removed since the request sync token was 332 generated, and it has not been re-mapped since it was removed. This 333 includes resources that have been unmapped as the result of a MOVE or 334 UNBIND ([I-D.ietf-webdav-bind]) operation. This also includes 335 collection resources that have been removed. 337 If a resource was created (and possibly modified), then removed in 338 between two synchronizations, it MUST be reported as removed. 340 A resource MAY be reported as removed if the user issuing the request 341 no longer has access to this resource, due to access control changes. 343 3.5. Truncation of Results 345 A server MAY limit the number of resources in a response, for 346 example, to limit the amount of work expended in processing a 347 request, or as the result of an explicit limit set by the client. If 348 the result set is truncated, the response MUST use status code 207, 349 return a DAV:multistatus response body, and indicate a status of 507 350 (Insufficient Storage) for the request URI. That DAV:response 351 element SHOULD include a DAV:error element with the DAV:number-of- 352 matches-within-limits precondition, as defined in [RFC3744] (Section 353 9.2). DAV:response elements for all the changes being reported are 354 also included. 356 When truncation occurs, the DAV:sync-token value returned in the 357 response MUST represent the correct state for the partial set of 358 changes returned. That allows the client to use the returned DAV: 359 sync-token to fetch the next set of changes. In this way the client 360 can effectively "page" through the entire set of changes in a 361 consistent manner. 363 Clients MUST handle the 507 status on the request-URI in the response 364 to the report. 366 For example, consider a server that records changes using a 367 monotonically increasing integer to represent a "revision number" and 368 uses that quantity as the DAV:sync-token value. Assume the last DAV: 369 sync-token used by the client was "10", and since then 20 additional 370 changes have occurred. If the client executes a DAV:sync-collection 371 request with a DAV:sync-token of "10", without a limit the server 372 would return 20 DAV:response elements and a DAV:sync-token with value 373 "30". But if the server choose to limit responses to at most 10 374 changes, then it would return only 10 DAV:response elements and a 375 DAV:sync-token with value "20", together with an addition DAV: 376 response element for the request-URI with a status code of 507. 377 Subsequently, the client can re-issue the request with the DAV:sync- 378 token value returned from the server and fetch the remaining 10 379 changes. 381 3.6. Limiting Results 383 A client can limit the number of results returned by the server 384 through use of the DAV:limit element ([RFC5323], Section 5.17) in the 385 request body. This is useful when clients have limited space or 386 bandwidth for the results. If a server is unable to truncate the 387 result at or below the requested number, then it MUST fail the 388 request with a DAV:number-of-matches-within-limits post-condition 389 error. When the results can be correctly limited by the server, the 390 server MUST follow the rules above for indicating a result set 391 truncation to the client. 393 3.7. Example: Initial DAV:sync-collection Report 395 In this example, the client is making its first synchronization 396 request to the server, so the DAV:sync-token element in the request 397 is empty. It also asks for the DAV:getetag property and for a 398 proprietary property. The server responds with the items currently 399 in the targeted collection. The current synchronization token is 400 also returned. 402 >> Request << 404 REPORT /home/cyrusdaboo/ HTTP/1.1 405 Host: webdav.example.com 406 Depth: 1 407 Content-Type: text/xml; charset="utf-8" 408 Content-Length: xxxx 410 411 412 413 414 415 416 417 419 >> Response << 421 HTTP/1.1 207 Multi-Status 422 Content-Type: text/xml; charset="utf-8" 423 Content-Length: xxxx 425 426 427 428 http://webdav.example.com/home/cyrusdaboo/test.doc 430 431 432 "00001-abcd1" 433 434 Box type A 435 436 437 HTTP/1.1 200 OK 438 439 440 441 http://webdav.example.com/home/cyrusdaboo/vcard.vcf 443 444 445 "00002-abcd1" 446 447 HTTP/1.1 200 OK 448 449 450 451 452 453 HTTP/1.1 404 Not Found 454 455 456 457 http://webdav.example.com/home/cyrusdaboo/calendar.ics 459 460 461 "00003-abcd1" 462 463 HTTP/1.1 200 OK 464 465 466 467 468 469 HTTP/1.1 404 Not Found 470 471 472 1234 473 475 3.8. Example: DAV:sync-collection Report with Token 477 In this example, the client is making a synchronization request to 478 the server and is using the DAV:sync-token element returned from the 479 last report it ran on this collection. The server responds, listing 480 the items that have been added, changed or removed. The (new) 481 current synchronization token is also returned. 483 >> Request << 485 REPORT /home/cyrusdaboo/ HTTP/1.1 486 Host: webdav.example.com 487 Depth: 1 488 Content-Type: text/xml; charset="utf-8" 489 Content-Length: xxxx 491 492 493 1234 494 495 496 497 498 499 >> Response << 501 HTTP/1.1 207 Multi-Status 502 Content-Type: text/xml; charset="utf-8" 503 Content-Length: xxxx 505 506 507 508 http://webdav.example.com/home/cyrusdaboo/file.xml 510 511 512 "00004-abcd1" 513 514 HTTP/1.1 200 OK 515 516 517 518 519 520 HTTP/1.1 404 Not Found 521 522 523 524 http://webdav.example.com/home/cyrusdaboo/vcard.vcf 526 527 528 "00002-abcd2" 529 530 HTTP/1.1 200 OK 531 532 533 534 535 536 HTTP/1.1 404 Not Found 537 538 539 540 http://webdav.example.com/home/cyrusdaboo/test.doc 542 HTTP/1.1 404 Not Found 543 544 1238 545 547 3.9. Example: Initial DAV:sync-collection Report with Truncation 549 In this example, the client is making its first synchronization 550 request to the server, so the DAV:sync-token element in the request 551 is empty. It also asks for the DAV:getetag property. The server 552 responds with the items currently in the targeted collection, but 553 truncated at two items. The synchronization token for the truncated 554 result set is returned. 556 >> Request << 558 REPORT /home/cyrusdaboo/ HTTP/1.1 559 Host: webdav.example.com 560 Depth: 1 561 Content-Type: text/xml; charset="utf-8" 562 Content-Length: xxxx 564 565 566 567 568 569 570 571 >> Response << 573 HTTP/1.1 207 Multi-Status 574 Content-Type: text/xml; charset="utf-8" 575 Content-Length: xxxx 577 578 579 580 http://webdav.example.com/home/cyrusdaboo/test.doc 582 583 584 "00001-abcd1" 585 586 HTTP/1.1 200 OK 587 588 589 590 http://webdav.example.com/home/cyrusdaboo/vcard.vcf 592 593 594 "00002-abcd1" 595 596 HTTP/1.1 200 OK 597 598 599 600 http://webdav.example.com/home/cyrusdaboo/ 602 HTTP/1.1 507 Insufficient Storage 603 604 1233 605 607 3.10. Example: Initial DAV:sync-collection Report with Limit 609 In this example, the client is making its first synchronization 610 request to the server, so the DAV:sync-token element in the request 611 is empty. It requests a limit of 1 for the responses returned by the 612 server. It also asks for the DAV:getetag property. The server 613 responds with the items currently in the targeted collection, but 614 truncated at one item. The synchronization token for the truncated 615 result set is returned. 617 >> Request << 619 REPORT /home/cyrusdaboo/ HTTP/1.1 620 Host: webdav.example.com 621 Depth: 1 622 Content-Type: text/xml; charset="utf-8" 623 Content-Length: xxxx 625 626 627 628 629 1 630 631 632 633 634 636 >> Response << 638 HTTP/1.1 207 Multi-Status 639 Content-Type: text/xml; charset="utf-8" 640 Content-Length: xxxx 642 643 644 645 http://webdav.example.com/home/cyrusdaboo/test.doc 647 648 649 "00001-abcd1" 650 651 HTTP/1.1 200 OK 652 653 654 655 http://webdav.example.com/home/cyrusdaboo/ 657 HTTP/1.1 507 Insufficient Storage 658 659 1232 660 662 3.11. Example: DAV:sync-collection Report with Unsupported Limit 664 In this example, the client is making a synchronization request to 665 the server with a valid DAV:sync-token element value. It requests a 666 limit of 100 for the responses returned by the server. It also asks 667 for the DAV:getetag property. The server is unable to limit the 668 results to the maximum specified by the client, so it responds with a 669 507 status code and appropriate post-condition error code. 671 >> Request << 673 REPORT /home/cyrusdaboo/ HTTP/1.1 674 Host: webdav.example.com 675 Depth: 1 676 Content-Type: text/xml; charset="utf-8" 677 Content-Length: xxxx 679 680 681 1232 682 683 100 684 685 686 687 688 690 >> Response << 692 HTTP/1.1 507 Insufficient Storage 693 Content-Type: text/xml; charset="utf-8" 694 Content-Length: xxxx 696 697 698 699 701 4. DAV:sync-token Property 702 Name: sync-token 704 Namespace: DAV: 706 Purpose: Contains the value of the synchronization token as it would 707 be returned by a DAV:sync-collection report. 709 Value: Any text. 711 Protected: MUST be protected because this value is created and 712 controlled by the server. 714 COPY/MOVE behavior: This property value is dependent on the final 715 state of the destination resource, not the value of the property 716 on the source resource. 718 Description: The DAV:sync-token property MUST be defined on all 719 resources that support the DAV:sync-collection report. It 720 contains the value of the synchronization token as it would be 721 returned by a DAV:sync-collection report on that resource at the 722 same point in time. It SHOULD NOT be returned by a PROPFIND DAV: 723 allprop request (as defined in [RFC4918]). 725 Definition: 727 729 5. XML Element Definitions 731 5.1. DAV:sync-collection XML Element 733 Name: sync-collection 735 Namespace: DAV: 737 Purpose: WebDAV report used to synchronize data between client and 738 server. 740 Description: See Section 3. 742 744 745 747 5.2. DAV:sync-token XML Element 749 Name: sync-token 751 Namespace: DAV: 753 Purpose: The synchronization token provided by the server and 754 returned by the client. 756 Description: See Section 3. 758 760 5.3. DAV:multistatus XML Element 762 Name: multistatus 764 Namespace: DAV: 766 Purpose: Extends the DAV:multistatus element to include 767 synchronization details. 769 Description: See Section 3. 771 774 776 777 779 6. Security Considerations 781 This extension does not introduce any new security concerns than 782 those already described in HTTP and WebDAV. 784 7. IANA Considerations 786 This document does not require any actions on the part of IANA. 788 8. Acknowledgments 790 The following individuals contributed their ideas and support for 791 writing this specification: Bernard Desruisseaux, Mike Douglass, Ciny 792 Joy, Andrew McMillan, Julian Reschke, and Wilfredo Sanchez. We would 793 like to thank the Calendaring and Scheduling Consortium for 794 facilitating interoperability testing for early implementations of 795 this specification. 797 9. References 799 9.1. Normative References 801 [RFC2119] Bradner, S., "Key words for use in RFCs 802 to Indicate Requirement Levels", BCP 14, 803 RFC 2119, March 1997. 805 [RFC2616] Fielding, R., Gettys, J., Mogul, J., 806 Frystyk, H., Masinter, L., Leach, P., 807 and T. Berners-Lee, "Hypertext Transfer 808 Protocol -- HTTP/1.1", RFC 2616, 809 June 1999. 811 [RFC3744] Clemm, G., Reschke, J., Sedlar, E., and 812 J. Whitehead, "Web Distributed Authoring 813 and Versioning (WebDAV) 814 Access Control Protocol", RFC 3744, 815 May 2004. 817 [RFC4918] Dusseault, L., "HTTP Extensions for Web 818 Distributed Authoring and Versioning 819 (WebDAV)", RFC 4918, June 2007. 821 [RFC5323] Reschke, J., Reddy, S., Davis, J., and 822 A. Babich, "Web Distributed Authoring 823 and Versioning (WebDAV) SEARCH", 824 RFC 5323, November 2008. 826 [W3C.REC-xml-20081126] Maler, E., Yergeau, F., Sperberg- 827 McQueen, C., Paoli, J., and T. Bray, 828 "Extensible Markup Language (XML) 1.0 829 (Fifth Edition)", World Wide Web 830 Consortium Recommendation REC-xml- 831 20081126, November 2008, . 834 9.2. Informative References 836 [I-D.ietf-vcarddav-carddav] Daboo, C., "vCard Extensions to WebDAV 837 (CardDAV)", 838 draft-ietf-vcarddav-carddav-10 (work in 839 progress), November 2009. 841 [I-D.ietf-webdav-bind] Clemm, G., Crawford, J., Reschke, J., 842 and J. Whitehead, "Binding Extensions to 843 Web Distributed Authoring and Versioning 844 (WebDAV)", draft-ietf-webdav-bind-27 845 (work in progress), December 2009. 847 [RFC4791] Daboo, C., Desruisseaux, B., and L. 848 Dusseault, "Calendaring Extensions to 849 WebDAV (CalDAV)", RFC 4791, March 2007. 851 Appendix A. Change History (to be removed prior to publication as an 852 RFC) 854 Changes in -03: 856 1. Changed D:propstat to D:prop in marshalling. 858 2. Added request for dead property in examples. 860 3. Made D:prop mandatory in request so that D:response always 861 contains at least one D:propstat as per WebDAV definition. 863 4. Removed DAV:status from response when resource is created/ 864 modified, thus allowing to get rid of DAV:sync-response in favor 865 of a regular DAV:response. As a consequence, there is no longer 866 any difference in the report between created and modified 867 resources. 869 5. Resource created, then removed between 2 sync MUST be returned as 870 removed. 872 6. Added ability for server to truncate results and indicate such to 873 the client. 875 7. Added ability for client to request the server to limit the 876 result set. 878 Changes in -02: 880 1. Added definition of sync-token WebDAV property. 882 2. Added references to SEARCH, CalDAV, CardDAV as alternative ways 883 to first synchronize a collection. 885 3. Added section defining under which condition each state change 886 (new, modified, removed) should be reported. Added reference to 887 BIND. 889 4. Incorporated feedback from Julian Reschke and Ciny Joy. 891 5. More details on the use of the DAV:valid-sync-token precondition. 893 Changes in -01: 895 1. Updated to 4918 reference. 897 2. Fixed examples to properly include DAV:status in DAV:propstat 899 3. Switch to using XML conventions text from RFC5323. 901 Authors' Addresses 903 Cyrus Daboo 904 Apple Inc. 905 1 Infinite Loop 906 Cupertino, CA 95014 907 USA 909 EMail: cyrus@daboo.name 910 URI: http://www.apple.com/ 912 Arnaud Quillaud 913 Sun Microsystems 914 180, Avenue de l'Europe 915 Saint Ismier cedex, 38334 916 France 918 EMail: arnaud.quillaud@sun.com 919 URI: http://www.sun.com/