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.