Transporting WebDAV-Related Event Notifications over the Extensible Messaging and Presence Protocol (XMPP)Jabber, Inc.jhildebrand@jabber.comJabber Software Foundationstpeter@jabber.org
Applications
WebDAVExtensible Messaging and Presence ProtocolXMPPevent notificationpublish-subscribeThis memo describes a method for notifying interested parties about WebDAV-related events (such as PUTs and DELETEs), where such notifications are delivered via an extension to the Extensible Messaging and Presence Protocol (XMPP) for publish-subscribe functionality. defines a set of extensions to for remote web content authoring operations. Entities that make use of such WebDAV services, which may include both human users and ancillary applications such as content management systems, may want to be notified when a WebDAV operation is applied to a web resource. For example, a human user may want to be notified whenever a particular shared resource is locked or unlocked, and an external auditing application may need to be informed whenever a resource is added, modified, or deleted. The methods of greatest interest will probably be COPY, DELETE, LOCK, MKCOL, MOVE, POST, PROPPATCH, PUT, and UNLOCK, but event notifications related to other methods may be appropriate, as well.Such notifications follow a classic "observer" or "publish-subscribe" design pattern: one entity initiates an event, and an event notification is broadcasted to all those who are interested in knowing when such events occur. Unfortunately, existing methods for learning that a resource has been updated are currently limited to "polling" for changes via HTTP, which is inherently inefficient. What is needed is a technology that can be relied on to "push" information only when a resource undergoes a state change, and only to those who are interested in learning about such state changes.One possible technology for doing so is email, since provides a way to initiate the sending of information from "publishers" to "subscribers" (think, for example, of email lists such as those used to announce newly-published RFCs). While email is one possible solution, it is not necessarily the best solution for WebDAV; in particular, defines XML data formats for method parameters and other metadata, which implies that it might be beneficial to use a native XML delivery mechanism rather than to attach a special XML media type to email messages. Thankfully, a specialized XML delivery protocol has been developed through the IETF: the Extensible Messaging and Presence Protocol (XMPP) as specified in . XMPP has the added benefit of being optimized for near-real-time data delivery, which may be important in applications of WebDAV that require subscribers to be notified about WebDAV-related events in a highly timely manner.While the semantics of a normal XMPP <message/> element may be suitable for WebDAV-related event notifications, there also exists an XMPP extension that provides more structured communications in the context of "topics" whose scope can be limited to a particular WebDAV resource or collection. This extension is specified in and may be especially useful for delivering notifications related to changes in WebDAV resources. Therefore, this memo describes a method for notifying interested parties about WebDAV-related events, where such notifications are delivered via the XMPP publish-subscribe extension.Several use cases originally motivated this proposal:A user who views a WebDAV collection through a file explorer application can use the notification protocol described herein to see in near-real-time when resources in the collection are successfully updated, locked, unlocked, etc.An application that replicates or mirrors an existing WebDAV repository can use the notification protocol described herein to stay synchronized with changes to the source repository, rather than updating less often in "batch" mode.When a client performs a WebDAV operation on a resource, many other entities may be interested in learning that the operation has successfully completed. The generalized process flow is as follows:A WebDAV client creates a resource at a WebDAV service.The WebDAV service sends an XMPP pubsub node creation request to an XMPP pubsub service and thereafter advertises availability of that pubsub node as a live property of the resource.One or more XMPP entities subscribe to the pubsub node.A WebDAV client requests completion of a WebDAV operation on the resource.The WebDAV service successfully completes the requested operation.The WebDAV service sends an appropriate XMPP pubsub request -- node creation, node deletion, or publish (with payload if appropriate) -- to the XMPP pubsub service.The XMPP pubsub service sends an XMPP message notification to each XMPP entity that subscribed to the pubsub node.The result is that the XMPP subscribers will receive near-real-time notification whenever a WebDAV operation has been completed on a resource of interest.The steps initiated by a WebDAV client in communication with a WebDAV service are out of scope for this memo, since they are described in and related memos. The XMPP protocols for the other steps are shown in the examples provided below.Note: This memo describes event notifications related to successful WebDAV operations only (i.e., operations that result in a 200-series acknowledgement from the WebDAV service to the WebDAV client). The pattern described herein could be used for unsuccessful operations as well (e.g., to address auditing use cases), but such usage is out of scope for this memo.We can visualize the architecture as follows:This document inherits terminology from , , and .The capitalized key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.The authors welcome discussion and comments related to the topics presented in this document. The preferred forum is the <w3c-dist-auth@w3.org> mailing list, for which subscription information and archive links are available at <http://www.ietf.org/html.charters/webdav-charter.html>.Thanks to Lisa Dusseault for helpful comments.This section describes the WebDAV properties that SHOULD be supported by a WebDAV service that publishes notifications to an XMPP pubsub service. Advertisement of these properties enables WebDAV clients and other entities to discover that a WebDAV service or specific resource supports the protocol defined herein.The "notify" property specifies whether XMPP pubsub notifications are published for a resource. The qualifying namespace is 'urn:ietf:params:xml:ns:webdav-event:prop:notify', the element name is <notify/>, and the allowable values of the character data are "true" and "false" (where "true" means that there exists an XMPP pubsub node associated with the resource, and "false" means that no such node exists). This property MUST be live and MAY be protected. The WebDAV service SHOULD advertise this property for each resource it hosts.A sample of the format is shown in the following WebDAV PROPFIND example.First, a client queries a specific WebDAV resource regarding this property.Then the WebDAV service responds with "true" or "false".The "node" property specifies the pubsub node at which notifications are published. The qualifying namespace is 'urn:ietf:params:xml:ns:webdav-event:prop:node', the element name is <node/>, and the character data of the <service/> and <nodeid/> children specify, respectively, the XMPP address of the pubsub service (in accordance with the definition of a JID in ) and the node ID at which notifications are published (in accordance with the definition of a pubsub NodeID in ). This property MUST be live and MAY be protected. The WebDAV service SHOULD advertise this property for each resource whose <notify/> property is "true".The syntax of the <nodeid/> element's character data is implementation-specific and therefore out of scope for this specification. If the pubsub service is a "dedicated" service connected only to the WebDAV service, the node ID could simply be the URI of the WebDAV resource (e.g., "http://example.com/foo/bar"). If the pubsub service is a generalized pubsub service that serves entities other than the WebDAV service, the pubsub node could be the WebDAV resource URI prepended by an implementation-specific or deployment-specific string such as "webdav|". Naturally, some other syntax is allowable as well, such as a SHA1-hash of the WebDAV resource URI.A sample of the format is shown in the following WebDAV PROPFIND example.First, a client queries a specific WebDAV resource regarding this property.Then the WebDAV service responds with the XMPP address of the pubsub service along with the specific node ID.In order to include payloads (rather than mere event notifications) in XMPP pubsub, it is necessary to re-use an existing XML format or define a new one. Since no existing format is fully appropriate for WebDAV-related events, we define a new payload format for use in WebDAV notifications. The "wrapper" for such payloads is a <webdav/> element qualified by the 'urn:ietf:params:xml:ns:webdav-event:payload' namespace; this wrapper element MUST possess two attributes: the 'method' attribute specifies which WebDAV method was applied, and the 'resource' attribute specifies the full URI of the resource to which the method was applied. The wrapper format is as follows:For certain operations, the wrapper element may provide complete information about the success of the operation. For example, this is true for the DELETE operation:The same is true of the UNLOCK operation:However, this is not true of all WebDAV operations, in which case the wrapper element MAY contain child elements that specify additional information about the operation. For example, a PUT or POST operation may result in changes to the resource (for which it would be helpful to receive a "diff"), a PROPPATCH operation may result in the application of new or changed properties (for which an XML format is defined in ), and other operations may result in a new ETag or output in some other XML format defined in . The following subsections specify the formats to be included as children of the event wrapper element.It is not necessary to define a payload format associated with the MKCOL operation, since that operation maps directly to node creation in the XMPP pubsub extension (where the node is a collection node). Similarly, a WebDAV PUT or POST operation that results in the creation of a new resource maps to node creation in the XMPP pubsub extension (where the node is not a collection node).Note: Line breaks in the following protocol descriptions are not significant and are included to improve readability only.The <activelock/> payload child (qualified by the 'DAV:' namespace) enables a WebDAV service to communicate the results of a LOCK request received from a WebDAV client (i.e., the fact that a resource is now locked).Note: A WebDAV service MAY send less information than shown above, and for security purposes SHOULD NOT include the <locktoken/> element described in .The <diff/> payload child (qualified by the 'urn:ietf:params:xml:ns:webdav-event:payload:diff' namespace) enables a WebDAV service to communicate the changes to a resource that resulted from a successful WebDAV operation (e.g., a POST or PUT). The XML character data of the <diff/> element MUST be encoded using base64, where the encoding adheres to the definition in Section 3 of RFC 3548. The value of the 'format' attribute specifies which diff format is used; possible values include, but are not limited to, "gdiff" (see and "vcdiff" (see ).The <diff/> payload child MAY also be published as a result of a successful PATCH operation (see ).The <etag/> payload child (qualified by the 'urn:ietf:params:xml:ns:webdav-event:payload:etag' namespace) enables a WebDAV service to communicate an entity tag related to a request received from a WebDAV client. The XML character data of the <etag/> element MUST be an ETag as defined in Sections 3.11 and 14.19 of .The <href/> payload child (qualified by the 'DAV:' namespace) enables a WebDAV service to communicate a URI resulting from a successful WebDAV COPY or MOVE operation as specified by the 'method' attribute of the <webdav/> element. For body COPY and MOVE, the 'resource' attribute of the <webdav/> element specifies the URI of the source resource, and the character data of the <href/> child specifies the URI of the destination resource.The <propertyupdate/> payload child (qualified by the 'DAV:' namespace) enables a WebDAV service to communicate the property update received from a WebDAV client during a PROPPATCH operation. The XML format for this element is defined in .This section currently provides several examples of process flows. We assume the following order of operations:A new collection "foo" is created at the example.com WebDAV service.A new resource "bar" is created within the "foo" collection.The "bar" resource is copied to the "newbar" resource.The properties of the "bar" resource are modified.The "bar" resource is locked.The "bar" resource is modified.The "bar" resource is unlocked.The "newbar" resource is deleted.We also assume that the entity "trackerbot@example.com" has an XMPP pubsub subscription of type "nodes" at depth='all' to the root pubsub collection node ("pubsub.example.com") and therefore receives notification regarding all new nodes and collections created at the pubsub service.Finally, we assume that the pubsub nodes are configured to deliver payloads, not just event notifications (since the <webdav/> wrapper element and its children are necessary in order to understand the full context of operations at the WebDAV service).Note: Line breaks in the following protocol examples are not significant and are included to improve readability only.First, a WebDAV client creates the "foo" collection by means of a MKCOL operation.Once the WebDAV service successfully creates the "foo" collection, it sends an XMPP pubsub collection node creation request to the XMPP pubsub service:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub node creation notification to each XMPP entity that has a subscription of type "nodes" to the root collection node (including our "TrackerBot"), where the payload contains the meta-data for the new collection node as described in . (Note that in accordance with the rules in allowing such behavior, the pubsub service has created a node ID of "webdav|http://example.com/foo" as a result of the request to create a node named "foo".)Next, a WebDAV client creates the "bar" resource in the "foo" collection (we assume by means of a PUT operation).Once the WebDAV service successfully creates the "bar" resource, it sends an XMPP pubsub node creation request to the XMPP pubsub service and associates the new node with the "foo" collection:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub node creation notification to each XMPP entity that has a subscription of type "nodes" to the root collection node or the "foo" collection node.Those informed of the new node may then decide to subscribe to it for pubsub item notifications; we shall assume that the TrackerBot does so:The pubsub service then replies with success:Next, a WebDAV client copies the "bar" resource to a new resource "newbar" by means of a COPY operation.Once the WebDAV service successfully copies the "bar" resource to the "newbar" resource, it (1) creates a new pubsub node for it (since the "newbar" resource is new and XMPP entities may want to know when it is modified, deleted, and so on), and (2) publishes an XMPP pubsub item to the "foo/bar" node at the XMPP pubsub service, including a <webdav/> wrapper element specifying a COPY operation and containing an <href/> child element:First, the WebDAV service sends an XMPP pubsub node creation request to the XMPP pubsub service and associates the new node with the "foo" collection:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub node creation notification to each XMPP entity that has a subscription of type "nodes" to the root collection node or the "foo" collection node.Those informed of the new node may then decide to subscribe to it for pubsub item notifications; we shall assume that the TrackerBot does so:The pubsub service then replies with success:Second, the WebDAV service publishes a COPY event to the pubsub node for the "bar" resource.If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub notification to each XMPP entity that has a subscription of type "items" to the "bar" node (or at depth='all' to any of its ancestor nodes).Next, a WebDAV client modifies the properties of the "bar" resource by means of a PROPPATCH operation.Once the WebDAV service successfully modifies the properties of the "bar" resource, it publishes an XMPP pubsub item to the "foo/bar" node at the XMPP pubsub service, including a <webdav/> wrapper element specifying a PROPPATCH method and containing a <propertyupdate/> child element:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub notification to each XMPP entity that has a subscription of type "items" to the "bar" node (or at depth='all' to any of its ancestor nodes).Next, a WebDAV client locks the "bar" resource by means of a LOCK operation.Once the WebDAV service successfully locks the "bar" resource, it publishes an XMPP pubsub item to the "foo/bar" node at the XMPP pubsub service, including a <webdav/> wrapper element specifying a LOCK method and containing an <activelock/> child element:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub notification to each XMPP entity that has a subscription of type "items" to the "bar" node (or at depth='all' to any of its ancestor nodes).Next, a WebDAV client modifies the "bar" resource (we assume by means of a PUT operation).Once the WebDAV service successfully modifies the "bar" resource, it publishes an XMPP pubsub item to the "foo/bar" node at the XMPP pubsub service, including a <webdav/> wrapper element specifying a PUT method and containing a <diff/> child element:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub notification to each XMPP entity that has a subscription of type "items" to the "bar" node (or at depth='all' to any of its ancestor nodes).Next, a WebDAV client unlocks the "bar" resource by means of an UNLOCK operation.Once the WebDAV service successfully unlocks the "bar" resource, it publishes an XMPP pubsub item to the "foo/bar" node at the XMPP pubsub service, including an empty <webdav/> wrapper element specifying an UNLOCK method:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub notification to each XMPP entity that has a subscription of type "items" to the "bar" node (or at depth='all' to any of its ancestor nodes).Next, a WebDAV client deletes the "newbar" resource by means of a DELETE operation.Once the WebDAV service successfully deletes the "newbar" resource, it publishes an XMPP pubsub item to the "foo/newbar" node at the XMPP pubsub service, including an empty <webdav/> wrapper element specifying a DELETE method:If no errors occur during processing of the foregoing XML stanza, the XMPP pubsub service then sends a pubsub notification to each XMPP entity that has a subscription of type "items" to the "newbar" node (or at depth='all' to any of its ancestor nodes).It might be assumed that it would be enough to delete the pubsub node when the corresponding WebDAV resource is deleted. However, there is not necessarily a one-to-one correspondence between WebDAV resources and pubsub nodes, and there may be good reasons to delete the pubsub node even if the WebDAV resource has not been deleted (e.g., "publish events" might be a property that can be set via PROPPATCH, and setting that property to "false" might result in deletion of the associated pubsub node). However, once the resource is deleted, the WebDAV service SHOULD also delete the associated pubsub node:Subscribers will then be notified that the node has been deleted:Detailed security considerations for the relevant protocols profiled in this memo are given in , , and .As far as possible, a WebDAV service SHOULD synchronize authorization between the WebDAV service and the XMPP pubsub service, using the subscription authorization protocol described in ; for example, a WebDAV service SHOULD NOT allow an entity to receive diffs via XMPP if such an entity would not be authorized to retrieve the resource via HTTP and its WebDAV extensions.The Base16, Base32, and Base64 Data EncodingsHypertext Transfer Protocol -- HTTP/1.1Department of Information and Computer ScienceUniversity of California, IrvineIrvineCA92697-3425+1(949)824-1715fielding@ics.uci.eduWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682jg@w3.orgCompaq Computer CorporationWestern Research Laboratory250 University AvenuePalo AltoCA94305mogul@wrl.dec.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682frystyk@w3.orgXerox CorporationMIT Laboratory for Computer Science, NE43-3563333 Coyote Hill RoadPalo AltoCA94034masinter@parc.xerox.comMicrosoft Corporation1 Microsoft WayRedmondWA98052paulle@microsoft.comWorld Wide Web ConsortiumMIT Laboratory for Computer Science, NE43-356545 Technology SquareCambridgeMA02139+1(617)258-8682timbl@w3.org
The Hypertext Transfer Protocol (HTTP) is an application-level
protocol for distributed, collaborative, hypermedia information
systems. It is a generic, stateless, protocol which can be used for
many tasks beyond its use for hypertext, such as name servers and
distributed object management systems, through extension of its
request methods, error codes and headers . A feature of HTTP is
the typing and negotiation of data representation, allowing systems
to be built independently of the data being transferred.
HTTP has been in use by the World-Wide Web global information
initiative since 1990. This specification defines the protocol
referred to as "HTTP/1.1", and is an update to RFC 2068 .
Key words for use in RFCs to Indicate Requirement LevelsHarvard University1350 Mass. Ave.CambridgeMA 02138- +1 617 495 3864-
General
keywordIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. Authors who follow these guidelines should incorporate this phrase near the beginning of their document:
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.Note that the force of these words is modified by the requirement level of the document in which they are used.HTTP Extensions for Distributed Authoring - WebDAV RFC2518 bisWebDAV consists of a set of methods, headers, and content-types ancillary to HTTP/1.1 for the management of resource properties, creation and management of resource collections, namespace manipulation, and resource locking (collision avoidance). RFC2518 was published in February 1998, and this draft makes minor revisions mostly due to interoperability experience.Extensible Messaging and Presence Protocol (XMPP): CoreJabber Software FoundationPublish-Subscribepgmillard@jabber.orgGeneric Diff Format SpecificationPartial Document Changes (PATCH Method) for HTTPSeveral applications extending HTTP require a feature to do partial resource modification. Existing HTTP functionality only allows a complete replacement of a document. This proposal adds a new HTTP method, PATCH, to modify an existing HTTP resource.Simple Mail Transfer ProtocolThe VCDIFF Generic Differencing and Compression Data Format