idnits 2.17.1 draft-hildebrand-webdav-notify-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1283. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1260. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1267. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1273. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 27 longer pages, the longest (page 28) being 70 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 29 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 28, 2004) is 7143 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 3548 (ref. 'BASE64') (Obsoleted by RFC 4648) ** Obsolete normative reference: RFC 2616 (ref. 'HTTP') (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) == Outdated reference: A later version (-18) exists of draft-ietf-webdav-rfc2518bis-06 -- Possible downref: Non-RFC (?) normative reference: ref. 'XMPP-PUBSUB' == Outdated reference: A later version (-16) exists of draft-dusseault-http-patch-04 -- Obsolete informational reference (is this intentional?): RFC 2821 (ref. 'SMTP') (Obsoleted by RFC 5321) Summary: 8 errors (**), 0 flaws (~~), 7 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Hildebrand 3 Internet-Draft Jabber, Inc. 4 Expires: March 29, 2005 P. Saint-Andre 5 Jabber Software Foundation 6 September 28, 2004 8 Transporting WebDAV-Related Event Notifications over the Extensible 9 Messaging and Presence Protocol (XMPP) 10 draft-hildebrand-webdav-notify-00 12 Status of this Memo 14 This document is an Internet-Draft and is subject to all provisions 15 of section 3 of RFC 3667. By submitting this Internet-Draft, each 16 author represents that any applicable patent or other IPR claims of 17 which he or she is aware have been or will be disclosed, and any of 18 which he or she become aware will be disclosed, in accordance with 19 RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as 24 Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 This Internet-Draft will expire on March 29, 2005. 39 Copyright Notice 41 Copyright (C) The Internet Society (2004). 43 Abstract 45 This memo describes a method for notifying interested parties about 46 WebDAV-related events (such as PUTs and DELETEs), where such 47 notifications are delivered via an extension to the Extensible 48 Messaging and Presence Protocol (XMPP) for publish-subscribe 49 functionality. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 1.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . 4 56 1.3 Process Flow . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.4 Architecture . . . . . . . . . . . . . . . . . . . . . . . 5 58 1.5 Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 59 1.6 Discussion Venue . . . . . . . . . . . . . . . . . . . . . 5 60 1.7 Acknowledgements . . . . . . . . . . . . . . . . . . . . . 6 61 2. Properties . . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 2.1 Pubsub Notification Property . . . . . . . . . . . . . . . 6 63 2.2 Pubsub Node Property . . . . . . . . . . . . . . . . . . . 7 64 3. Payload Format . . . . . . . . . . . . . . . . . . . . . . . . 8 65 3.1 Wrapper Element . . . . . . . . . . . . . . . . . . . . . 8 66 3.2 Element . . . . . . . . . . . . . . . . . . 10 67 3.3 Element . . . . . . . . . . . . . . . . . . . . . 10 68 3.4 Element . . . . . . . . . . . . . . . . . . . . . 11 69 3.5 Element . . . . . . . . . . . . . . . . . . . . . 11 70 3.6 Element . . . . . . . . . . . . . . . . 12 71 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 4.1 Collection Created . . . . . . . . . . . . . . . . . . . . 13 73 4.2 Resource Created . . . . . . . . . . . . . . . . . . . . . 14 74 4.3 Resource Copied . . . . . . . . . . . . . . . . . . . . . 16 75 4.4 Properties Modified . . . . . . . . . . . . . . . . . . . 19 76 4.5 Resource Locked . . . . . . . . . . . . . . . . . . . . . 21 77 4.6 Resource Modified . . . . . . . . . . . . . . . . . . . . 23 78 4.7 Resource Unlocked . . . . . . . . . . . . . . . . . . . . 25 79 4.8 Resource Deleted . . . . . . . . . . . . . . . . . . . . . 26 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 81 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 82 6.1 Normative References . . . . . . . . . . . . . . . . . . . . 27 83 6.2 Informative References . . . . . . . . . . . . . . . . . . . 28 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28 85 Intellectual Property and Copyright Statements . . . . . . . . 29 87 1. Introduction 89 1.1 Overview 91 [WEBDAV] defines a set of extensions to [HTTP] for remote web content 92 authoring operations. Entities that make use of such WebDAV 93 services, which may include both human users and ancillary 94 applications such as content management systems, may want to be 95 notified when a WebDAV operation is applied to a web resource. For 96 example, a human user may want to be notified whenever a particular 97 shared resource is locked or unlocked, and an external auditing 98 application may need to be informed whenever a resource is added, 99 modified, or deleted. The methods of greatest interest will probably 100 be COPY, DELETE, LOCK, MKCOL, MOVE, POST, PROPPATCH, PUT, and UNLOCK, 101 but event notifications related to other methods may be appropriate, 102 as well. 104 Such notifications follow a classic "observer" or "publish-subscribe" 105 design pattern: one entity initiates an event, and an event 106 notification is broadcasted to all those who are interested in 107 knowing when such events occur. Unfortunately, existing methods for 108 learning that a resource has been updated are currently limited to 109 "polling" for changes via HTTP, which is inherently inefficient. 110 What is needed is a technology that can be relied on to "push" 111 information only when a resource undergoes a state change, and only 112 to those who are interested in learning about such state changes. 114 One possible technology for doing so is email, since [SMTP] provides 115 a way to initiate the sending of information from "publishers" to 116 "subscribers" (think, for example, of email lists such as those used 117 to announce newly-published RFCs). While email is one possible 118 solution, it is not necessarily the best solution for WebDAV; in 119 particular, [WEBDAV] defines XML data formats for method parameters 120 and other metadata, which implies that it might be beneficial to use 121 a native XML delivery mechanism rather than to attach a special XML 122 media type to email messages. Thankfully, a specialized XML delivery 123 protocol has been developed through the IETF: the Extensible 124 Messaging and Presence Protocol (XMPP) as specified in [XMPP-CORE]. 125 XMPP has the added benefit of being optimized for near-real-time data 126 delivery, which may be important in applications of WebDAV that 127 require subscribers to be notified about WebDAV-related events in a 128 highly timely manner. 130 While the semantics of a normal XMPP element may be 131 suitable for WebDAV-related event notifications, there also exists an 132 XMPP extension that provides more structured communications in the 133 context of "topics" whose scope can be limited to a particular WebDAV 134 resource or collection. This extension is specified in [XMPP-PUBSUB] 135 and may be especially useful for delivering notifications related to 136 changes in WebDAV resources. Therefore, this memo describes a method 137 for notifying interested parties about WebDAV-related events, where 138 such notifications are delivered via the XMPP publish-subscribe 139 extension. 141 1.2 Use Cases 143 Several use cases originally motivated this proposal: 145 1. A user who views a WebDAV collection through a file explorer 146 application can use the notification protocol described herein to 147 see in near-real-time when resources in the collection are 148 successfully updated, locked, unlocked, etc. 149 2. An application that replicates or mirrors an existing WebDAV 150 repository can use the notification protocol described herein to 151 stay synchronized with changes to the source repository, rather 152 than updating less often in "batch" mode. 154 1.3 Process Flow 156 When a client performs a WebDAV operation on a resource, many other 157 entities may be interested in learning that the operation has 158 successfully completed. The generalized process flow is as follows: 160 o A WebDAV client creates a resource at a WebDAV service. 161 o The WebDAV service sends an XMPP pubsub node creation request to 162 an XMPP pubsub service and thereafter advertises availability of 163 that pubsub node as a live property of the resource. 164 o One or more XMPP entities subscribe to the pubsub node. 165 o A WebDAV client requests completion of a WebDAV operation on the 166 resource. 167 o The WebDAV service successfully completes the requested operation. 168 o The WebDAV service sends an appropriate XMPP pubsub request -- 169 node creation, node deletion, or publish (with payload if 170 appropriate) -- to the XMPP pubsub service. 171 o The XMPP pubsub service sends an XMPP message notification to each 172 XMPP entity that subscribed to the pubsub node. 174 The result is that the XMPP subscribers will receive near-real-time 175 notification whenever a WebDAV operation has been completed on a 176 resource of interest. 178 The steps initiated by a WebDAV client in communication with a WebDAV 179 service are out of scope for this memo, since they are described in 180 [WEBDAV] and related memos. The XMPP protocols for the other steps 181 are shown in the examples provided below. 183 Note: This memo describes event notifications related to successful 184 WebDAV operations only (i.e., operations that result in a 200-series 185 acknowledgement from the WebDAV service to the WebDAV client). The 186 pattern described herein could be used for unsuccessful operations as 187 well (e.g., to address auditing use cases), but such usage is out of 188 scope for this memo. 190 1.4 Architecture 192 We can visualize the architecture as follows: 194 +---------------+ 195 | WebDAV Client | 196 +---------------+ 197 | 198 | [HTTP/1.1 + WebDAV] 199 | 200 +----------------+ 201 | WebDAV Service | 202 +----------------+ 203 | 204 | [XMPP + Pubsub Extension] 205 | 206 +---------------------+ 207 | XMPP Pubsub Service | 208 +---------------------+ 209 | 210 | [XMPP + Pubsub Extension] 211 | 212 +-------------+ 213 | XMPP Entity | 214 +-------------+ 216 1.5 Terminology 218 This document inherits terminology from [WEBDAV], [XMPP-CORE], and 219 [XMPP-PUBSUB]. 221 The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", 222 "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 223 "OPTIONAL" in this document are to be interpreted as described in RFC 224 2119 [TERMS]. 226 1.6 Discussion Venue 228 The authors welcome discussion and comments related to the topics 229 presented in this document. The preferred forum is the 230 mailing list, for which subscription 231 information and archive links are available at <>. 233 1.7 Acknowledgements 235 Thanks to Lisa Dusseault for helpful comments. 237 2. Properties 239 This section describes the WebDAV properties that SHOULD be supported 240 by a WebDAV service that publishes notifications to an XMPP pubsub 241 service. Advertisement of these properties enables WebDAV clients 242 and other entities to discover that a WebDAV service or specific 243 resource supports the protocol defined herein. 245 2.1 Pubsub Notification Property 247 The "notify" property specifies whether XMPP pubsub notifications are 248 published for a resource. The qualifying namespace is 249 'urn:ietf:params:xml:ns:webdav-event:prop:notify', the element name 250 is , and the allowable values of the character data are 251 "true" and "false" (where "true" means that there exists an XMPP 252 pubsub node associated with the resource, and "false" means that no 253 such node exists). This property MUST be live and MAY be protected. 254 The WebDAV service SHOULD advertise this property for each resource 255 it hosts. 257 A sample of the format is shown in the following WebDAV PROPFIND 258 example. 260 First, a client queries a specific WebDAV resource regarding this 261 property. 263 PROPFIND /foo/bar HTTP/1.1 264 Host: example.com 265 Depth: 1 266 Content-Type: text/xml; charset="utf-8" 267 Content-Length: xxxx 269 270 271 272 274 275 277 Then the WebDAV service responds with "true" or "false". 279 HTTP/1.1 207 Multi-Status 280 Date: Mon, 27 Sep 2004 19:52:01 GMT 281 Content-Type: text/xml; charset="utf-8" 282 Content-Length: xxxx 284 285 286 287 http://example.com/foo/bar 288 289 291 true 292 293 HTTT//1.1 200 OK 294 295 296 298 2.2 Pubsub Node Property 300 The "node" property specifies the pubsub node at which notifications 301 are published. The qualifying namespace is 302 'urn:ietf:params:xml:ns:webdav-event:prop:node', the element name is 303 , and the character data of the and 304 children specify, respectively, the XMPP address of the pubsub 305 service (in accordance with the definition of a JID in [XMPP-CORE]) 306 and the node ID at which notifications are published (in accordance 307 with the definition of a pubsub NodeID in [XMPP-PUBSUB]). This 308 property MUST be live and MAY be protected. The WebDAV service 309 SHOULD advertise this property for each resource whose 310 property is "true". 312 The syntax of the element's character data is 313 implementation-specific and therefore out of scope for this 314 specification. If the pubsub service is a "dedicated" service 315 connected only to the WebDAV service, the node ID could simply be the 316 URI of the WebDAV resource (e.g., "http://example.com/foo/bar"). If 317 the pubsub service is a generalized pubsub service that serves 318 entities other than the WebDAV service, the pubsub node could be the 319 WebDAV resource URI prepended by an implementation-specific or 320 deployment-specific string such as "webdav|". Naturally, some other 321 syntax is allowable as well, such as a SHA1-hash of the WebDAV 322 resource URI. 324 A sample of the format is shown in the following WebDAV PROPFIND 325 example. 327 First, a client queries a specific WebDAV resource regarding this 328 property. 330 PROPFIND /foo/bar HTTP/1.1 331 Host: example.com 332 Depth: 1 333 Content-Type: text/xml; charset="utf-8" 334 Content-Length: xxxx 336 337 338 339 341 342 344 Then the WebDAV service responds with the XMPP address of the pubsub 345 service along with the specific node ID. 347 HTTP/1.1 207 Multi-Status 348 Date: Mon, 27 Sep 2004 20:06:38 GMT 349 Content-Type: text/xml; charset="utf-8" 350 Content-Length: xxxx 352 353 354 355 http://example.com/foo/bar 356 357 358 pubsub.example.com 359 webdav|http://example.com/foo/bar 360 361 HTTT//1.1 200 OK 362 363 364 366 3. Payload Format 368 3.1 Wrapper Element 370 In order to include payloads (rather than mere event notifications) 371 in XMPP pubsub, it is necessary to re-use an existing XML format or 372 define a new one. Since no existing format is fully appropriate for 373 WebDAV-related events, we define a new payload format for use in 374 WebDAV notifications. The "wrapper" for such payloads is a 375 element qualified by the 376 'urn:ietf:params:xml:ns:webdav-event:payload' namespace; this wrapper 377 element MUST possess two attributes: the 'method' attribute specifies 378 which WebDAV method was applied, and the 'resource' attribute 379 specifies the full URI of the resource to which the method was 380 applied. The wrapper format is as follows: 382 385 [ OPTIONAL PAYLOAD ELEMENTS ] 386 388 For certain operations, the wrapper element may provide complete 389 information about the success of the operation. For example, this is 390 true for the DELETE operation: 392 396 The same is true of the UNLOCK operation: 398 402 However, this is not true of all WebDAV operations, in which case the 403 wrapper element MAY contain child elements that specify additional 404 information about the operation. For example, a PUT or POST 405 operation may result in changes to the resource (for which it would 406 be helpful to receive a "diff"), a PROPPATCH operation may result in 407 the application of new or changed properties (for which an XML format 408 is defined in [WEBDAV]), and other operations may result in a new 409 ETag or output in some other XML format defined in [WEBDAV]. The 410 following subsections specify the formats to be included as children 411 of the event wrapper element. 413 It is not necessary to define a payload format associated with the 414 MKCOL operation, since that operation maps directly to node creation 415 in the XMPP pubsub extension (where the node is a collection node). 416 Similarly, a WebDAV PUT or POST operation that results in the 417 creation of a new resource maps to node creation in the XMPP pubsub 418 extension (where the node is not a collection node). 420 Note: Line breaks in the following protocol descriptions are not 421 significant and are included to improve readability only. 423 3.2 Element 425 The payload child (qualified by the 'DAV:' namespace) 426 enables a WebDAV service to communicate the results of a LOCK request 427 received from a WebDAV client (i.e., the fact that a resource is now 428 locked). 430 433 434 435 436 infinity 437 438 439 http://jabber.org/people/stpeter.php 440 441 442 Second-604800 443 444 http://example.com/foo/bar 445 446 447 449 Note: A WebDAV service MAY send less information than shown above, 450 and for security purposes SHOULD NOT include the element 451 described in [WEBDAV]. 453 3.3 Element 455 The payload child (qualified by the 456 'urn:ietf:params:xml:ns:webdav-event:payload:diff' namespace) enables 457 a WebDAV service to communicate the changes to a resource that 458 resulted from a successful WebDAV operation (e.g., a POST or PUT). 459 The XML character data of the element MUST be encoded using 460 base64, where the encoding adheres to the definition in Section 3 of 461 RFC 3548 [BASE64]. The value of the 'format' attribute specifies 462 which diff format is used; possible values include, but are not 463 limited to, "gdiff" (see [GDIFF] and "vcdiff" (see [VCDIFF]). 465 468 470 base64 472 473 475 The payload child MAY also be published as a result of a 476 successful PATCH operation (see [PATCH]). 478 3.4 Element 480 The payload child (qualified by the 481 'urn:ietf:params:xml:ns:webdav-event:payload:etag' namespace) enables 482 a WebDAV service to communicate an entity tag related to a request 483 received from a WebDAV client. The XML character data of the 484 element MUST be an ETag as defined in Sections 3.11 and 14.19 of 485 [HTTP]. 487 490 491 some-entity-tag 492 493 495 3.5 Element 497 The payload child (qualified by the 'DAV:' namespace) enables 498 a WebDAV service to communicate a URI resulting from a successful 499 WebDAV COPY or MOVE operation as specified by the 'method' attribute 500 of the element. For body COPY and MOVE, the 'resource' 501 attribute of the element specifies the URI of the source 502 resource, and the character data of the child specifies the 503 URI of the destination resource. 505 508 http://example.com/foo/newbar 509 511 514 http://example.com/foo/newbar 515 517 3.6 Element 519 The payload child (qualified by the 'DAV:' 520 namespace) enables a WebDAV service to communicate the property 521 update received from a WebDAV client during a PROPPATCH operation. 522 The XML format for this element is defined in [WEBDAV]. 524 527 528 529 530 true 531 532 533 534 536 4. Examples 538 This section currently provides several examples of process flows. 539 We assume the following order of operations: 541 1. A new collection "foo" is created at the example.com WebDAV 542 service. 543 2. A new resource "bar" is created within the "foo" collection. 544 3. The "bar" resource is copied to the "newbar" resource. 545 4. The properties of the "bar" resource are modified. 546 5. The "bar" resource is locked. 547 6. The "bar" resource is modified. 548 7. The "bar" resource is unlocked. 549 8. The "newbar" resource is deleted. 551 We also assume that the entity "trackerbot@example.com" has an XMPP 552 pubsub subscription of type "nodes" at depth='all' to the root pubsub 553 collection node ("pubsub.example.com") and therefore receives 554 notification regarding all new nodes and collections created at the 555 pubsub service. 557 Finally, we assume that the pubsub nodes are configured to deliver 558 payloads, not just event notifications (since the wrapper 559 element and its children are necessary in order to understand the 560 full context of operations at the WebDAV service). 562 Note: Line breaks in the following protocol examples are not 563 significant and are included to improve readability only. 565 4.1 Collection Created 567 First, a WebDAV client creates the "foo" collection by means of a 568 MKCOL operation. 570 Once the WebDAV service successfully creates the "foo" collection, it 571 sends an XMPP pubsub collection node creation request to the XMPP 572 pubsub service: 574 578 579 580 581 582 583 584 http://jabber.org/protocol/pubsub#node_config 585 586 587 588 collection 589 590 591 592 593 595 If no errors occur during processing of the foregoing XML stanza, the 596 XMPP pubsub service then sends a pubsub node creation notification to 597 each XMPP entity that has a subscription of type "nodes" to the root 598 collection node (including our "TrackerBot"), where the payload 599 contains the meta-data for the new collection node as described in 600 [XMPP-PUBSUB]. (Note that in accordance with the rules in 601 [XMPP-PUBSUB] allowing such behavior, the pubsub service has created 602 a node ID of "webdav|http://example.com/foo" as a result of the 603 request to create a node named "foo".) 604 606 607 608 609 610 611 612 http://jabber.org/protocol/pubsub#meta-data 613 614 615 617 2004-09-23T17:23Z 618 619 620 webdav-service.example.com 621 622 623 urn:ietf:params:xml:ns:webdav-event 624 625 626 627 628 630 4.2 Resource Created 632 Next, a WebDAV client creates the "bar" resource in the "foo" 633 collection (we assume by means of a PUT operation). 635 Once the WebDAV service successfully creates the "bar" resource, it 636 sends an XMPP pubsub node creation request to the XMPP pubsub service 637 and associates the new node with the "foo" collection: 639 643 644 645 646 647 648 foo 649 650 651 652 653 655 If no errors occur during processing of the foregoing XML stanza, the 656 XMPP pubsub service then sends a pubsub node creation notification to 657 each XMPP entity that has a subscription of type "nodes" to the root 658 collection node or the "foo" collection node. 660 662 663 664 665 666 667 668 http://jabber.org/protocol/pubsub#meta-data 669 670 671 673 2004-09-23T17:26Z 674 675 676 webdav-service.example.com 677 678 679 urn:ietf:params:xml:ns:webdav-event 680 681 682 683 684 686 Those informed of the new node may then decide to subscribe to it for 687 pubsub item notifications; we shall assume that the TrackerBot does 688 so: 690 694 695 698 699 701 The pubsub service then replies with success: 703 707 708 714 715 717 4.3 Resource Copied 719 Next, a WebDAV client copies the "bar" resource to a new resource 720 "newbar" by means of a COPY operation. 722 Once the WebDAV service successfully copies the "bar" resource to the 723 "newbar" resource, it (1) creates a new pubsub node for it (since the 724 "newbar" resource is new and XMPP entities may want to know when it 725 is modified, deleted, and so on), and (2) publishes an XMPP pubsub 726 item to the "foo/bar" node at the XMPP pubsub service, including a 727 wrapper element specifying a COPY operation and containing 728 an child element: 730 First, the WebDAV service sends an XMPP pubsub node creation request 731 to the XMPP pubsub service and associates the new node with the "foo" 732 collection: 734 738 739 740 741 742 743 foo 744 745 746 747 748 750 If no errors occur during processing of the foregoing XML stanza, the 751 XMPP pubsub service then sends a pubsub node creation notification to 752 each XMPP entity that has a subscription of type "nodes" to the root 753 collection node or the "foo" collection node. 755 757 758 759 760 761 762 763 http://jabber.org/protocol/pubsub#meta-data 764 765 766 768 2004-09-23T20:22Z 769 770 771 webdav-service.example.com 772 773 774 urn:ietf:params:xml:ns:webdav-event 775 776 777 778 779 781 Those informed of the new node may then decide to subscribe to it for 782 pubsub item notifications; we shall assume that the TrackerBot does 783 so: 785 789 790 793 794 796 The pubsub service then replies with success: 798 802 803 809 810 812 Second, the WebDAV service publishes a COPY event to the pubsub node 813 for the "bar" resource. 815 819 820 821 822 826 827 http://example.com/foo/newbar 828 829 830 831 832 833 835 If no errors occur during processing of the foregoing XML stanza, the 836 XMPP pubsub service then sends a pubsub notification to each XMPP 837 entity that has a subscription of type "items" to the "bar" node (or 838 at depth='all' to any of its ancestor nodes). 840 842 843 844 845 849 850 http://example.com/foo/newbar 851 852 853 854 855 856 858 4.4 Properties Modified 860 Next, a WebDAV client modifies the properties of the "bar" resource 861 by means of a PROPPATCH operation. 863 Once the WebDAV service successfully modifies the properties of the 864 "bar" resource, it publishes an XMPP pubsub item to the "foo/bar" 865 node at the XMPP pubsub service, including a wrapper 866 element specifying a PROPPATCH method and containing a 867 child element: 869 873 874 875 876 880 881 882 883 884 true 885 886 887 888 889 890 891 892 893 895 If no errors occur during processing of the foregoing XML stanza, the 896 XMPP pubsub service then sends a pubsub notification to each XMPP 897 entity that has a subscription of type "items" to the "bar" node (or 898 at depth='all' to any of its ancestor nodes). 900 902 903 904 905 909 910 911 912 913 true 914 915 916 917 918 919 920 921 922 924 4.5 Resource Locked 926 Next, a WebDAV client locks the "bar" resource by means of a LOCK 927 operation. 929 Once the WebDAV service successfully locks the "bar" resource, it 930 publishes an XMPP pubsub item to the "foo/bar" node at the XMPP 931 pubsub service, including a wrapper element specifying a 932 LOCK method and containing an child element: 934 938 939 940 941 945 946 947 948 infinity 949 950 951 http://jabber.org/people/stpeter.php 952 953 954 Second-604800 955 956 957 opaquelocktoken:e71d4fae-5dec-22d6-\ 958 fea5-00a0c91e6be4 959 960 961 962 http://example.com/foo/bar 963 964 965 966 967 968 969 971 If no errors occur during processing of the foregoing XML stanza, the 972 XMPP pubsub service then sends a pubsub notification to each XMPP 973 entity that has a subscription of type "items" to the "bar" node (or 974 at depth='all' to any of its ancestor nodes). 976 978 979 980 981 985 986 987 988 infinity 989 990 991 http://jabber.org/people/stpeter.php 992 993 994 Second-604800 995 996 997 opaquelocktoken:e71d4fae-5dec-22d6-\ 998 fea5-00a0c91e6be4 999 1000 1001 1002 http://example.com/foo/bar 1003 1004 1005 1006 1007 1008 1009 1011 4.6 Resource Modified 1013 Next, a WebDAV client modifies the "bar" resource (we assume by means 1014 of a PUT operation). 1016 Once the WebDAV service successfully modifies the "bar" resource, it 1017 publishes an XMPP pubsub item to the "foo/bar" node at the XMPP 1018 pubsub service, including a wrapper element specifying a 1019 PUT method and containing a child element: 1021 1025 1026 1027 1028 1032 1034 base64 1035 1036 1037 1038 1039 1040 1042 If no errors occur during processing of the foregoing XML stanza, the 1043 XMPP pubsub service then sends a pubsub notification to each XMPP 1044 entity that has a subscription of type "items" to the "bar" node (or 1045 at depth='all' to any of its ancestor nodes). 1047 1049 1050 1051 1052 1056 1058 base64 1059 1060 1061 1062 1063 1064 1066 4.7 Resource Unlocked 1068 Next, a WebDAV client unlocks the "bar" resource by means of an 1069 UNLOCK operation. 1071 Once the WebDAV service successfully unlocks the "bar" resource, it 1072 publishes an XMPP pubsub item to the "foo/bar" node at the XMPP 1073 pubsub service, including an empty wrapper element 1074 specifying an UNLOCK method: 1076 1080 1081 1082 1083 1087 1088 1089 1090 1092 If no errors occur during processing of the foregoing XML stanza, the 1093 XMPP pubsub service then sends a pubsub notification to each XMPP 1094 entity that has a subscription of type "items" to the "bar" node (or 1095 at depth='all' to any of its ancestor nodes). 1097 1099 1100 1101 1102 1106 1107 1108 1109 1111 4.8 Resource Deleted 1113 Next, a WebDAV client deletes the "newbar" resource by means of a 1114 DELETE operation. 1116 Once the WebDAV service successfully deletes the "newbar" resource, 1117 it publishes an XMPP pubsub item to the "foo/newbar" node at the XMPP 1118 pubsub service, including an empty wrapper element 1119 specifying a DELETE method: 1121 1125 1126 1127 1128 1132 1133 1134 1135 1137 If no errors occur during processing of the foregoing XML stanza, the 1138 XMPP pubsub service then sends a pubsub notification to each XMPP 1139 entity that has a subscription of type "items" to the "newbar" node 1140 (or at depth='all' to any of its ancestor nodes). 1142 1144 1145 1146 1147 1151 1152 1153 1154 1156 It might be assumed that it would be enough to delete the pubsub node 1157 when the corresponding WebDAV resource is deleted. However, there is 1158 not necessarily a one-to-one correspondence between WebDAV resources 1159 and pubsub nodes, and there may be good reasons to delete the pubsub 1160 node even if the WebDAV resource has not been deleted (e.g., "publish 1161 events" might be a property that can be set via PROPPATCH, and 1162 setting that property to "false" might result in deletion of the 1163 associated pubsub node). However, once the resource is deleted, the 1164 WebDAV service SHOULD also delete the associated pubsub node: 1166 1170 1171 1172 1173 1175 Subscribers will then be notified that the node has been deleted: 1177 1179 1180 1181 1182 1184 5. Security Considerations 1186 Detailed security considerations for the relevant protocols profiled 1187 in this memo are given in [WEBDAV], [XMPP-CORE], and [XMPP-PUBSUB]. 1189 As far as possible, a WebDAV service SHOULD synchronize authorization 1190 between the WebDAV service and the XMPP pubsub service, using the 1191 subscription authorization protocol described in [XMPP-PUBSUB]; for 1192 example, a WebDAV service SHOULD NOT allow an entity to receive diffs 1193 via XMPP if such an entity would not be authorized to retrieve the 1194 resource via HTTP and its WebDAV extensions. 1196 6. References 1198 6.1 Normative References 1200 [BASE64] Josefsson, S., "The Base16, Base32, and Base64 Data 1201 Encodings", RFC 3548, July 2003. 1203 [HTTP] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1204 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 1205 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1207 [TERMS] Bradner, S., "Key words for use in RFCs to Indicate 1208 Requirement Levels", BCP 14, RFC 2119, March 1997. 1210 [WEBDAV] Dusseault, L. and J. Crawford, "HTTP Extensions for 1211 Distributed Authoring - WebDAV RFC2518 bis", 1212 draft-ietf-webdav-rfc2518bis-06 (work in progress), July 1213 2004. 1215 [XMPP-CORE] 1216 Saint-Andre, P., "Extensible Messaging and Presence 1217 Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in 1218 progress), May 2004. 1220 [XMPP-PUBSUB] 1221 Millard, P., "Publish-Subscribe", JSF JEP 0060, July 2004. 1223 6.2 Informative References 1225 [GDIFF] Hoff, A. and J. Payne, "Generic Diff Format Specification", 1226 W3C NOTE NOTE-gdiff-19970901, September 1997. 1228 [PATCH] Dusseault, L., "Partial Document Changes (PATCH Method) for 1229 HTTP", draft-dusseault-http-patch-04 (work in progress), 1230 August 2004. 1232 [SMTP] Klensin, J., "Simple Mail Transfer Protocol", RFC 2821, 1233 April 2001. 1235 [VCDIFF] Korn, D., MacDonald, J., Mogul, J. and K. Vo, "The VCDIFF 1236 Generic Differencing and Compression Data Format", RFC 1237 3284, June 2002. 1239 Authors' Addresses 1241 Joe Hildebrand 1242 Jabber, Inc. 1244 EMail: jhildebrand@jabber.com 1246 Peter Saint-Andre 1247 Jabber Software Foundation 1249 EMail: stpeter@jabber.org 1251 Intellectual Property Statement 1253 The IETF takes no position regarding the validity or scope of any 1254 Intellectual Property Rights or other rights that might be claimed to 1255 pertain to the implementation or use of the technology described in 1256 this document or the extent to which any license under such rights 1257 might or might not be available; nor does it represent that it has 1258 made any independent effort to identify any such rights. Information 1259 on the procedures with respect to rights in RFC documents can be 1260 found in BCP 78 and BCP 79. 1262 Copies of IPR disclosures made to the IETF Secretariat and any 1263 assurances of licenses to be made available, or the result of an 1264 attempt made to obtain a general license or permission for the use of 1265 such proprietary rights by implementers or users of this 1266 specification can be obtained from the IETF on-line IPR repository at 1267 http://www.ietf.org/ipr. 1269 The IETF invites any interested party to bring to its attention any 1270 copyrights, patents or patent applications, or other proprietary 1271 rights that may cover technology that may be required to implement 1272 this standard. Please address the information to the IETF at 1273 ietf-ipr@ietf.org. 1275 Disclaimer of Validity 1277 This document and the information contained herein are provided on an 1278 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1279 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1280 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1281 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1282 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1283 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1285 Copyright Statement 1287 Copyright (C) The Internet Society (2004). This document is subject 1288 to the rights, licenses and restrictions contained in BCP 78, and 1289 except as set forth therein, the authors retain all their rights. 1291 Acknowledgment 1293 Funding for the RFC Editor function is currently provided by the 1294 Internet Society.