Network Working Group                                      J. Hildebrand
Internet-Draft                                              Jabber, Inc.
Expires: March 29, 2005                                   P. Saint-Andre
                                              Jabber Software Foundation
                                                      September 28, 2004



  Transporting WebDAV-Related Event Notifications over the Extensible
                 Messaging and Presence Protocol (XMPP)
                   draft-hildebrand-webdav-notify-00


Status of this Memo


   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 become aware will be disclosed, in accordance with
   RFC 3668.


   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as
   Internet-Drafts.


   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."


   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.


   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.


   This Internet-Draft will expire on March 29, 2005.


Copyright Notice


   Copyright (C) The Internet Society (2004).


Abstract


   This 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.




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 1]
Internet-Draft               WEBDAV-EVENTS                September 2004



Table of Contents


   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.1   Overview . . . . . . . . . . . . . . . . . . . . . . . . .  3
     1.2   Use Cases  . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.3   Process Flow . . . . . . . . . . . . . . . . . . . . . . .  4
     1.4   Architecture . . . . . . . . . . . . . . . . . . . . . . .  5
     1.5   Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.6   Discussion Venue . . . . . . . . . . . . . . . . . . . . .  5
     1.7   Acknowledgements . . . . . . . . . . . . . . . . . . . . .  6
   2.  Properties . . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.1   Pubsub Notification Property . . . . . . . . . . . . . . .  6
     2.2   Pubsub Node Property . . . . . . . . . . . . . . . . . . .  7
   3.  Payload Format . . . . . . . . . . . . . . . . . . . . . . . .  8
     3.1   Wrapper Element  . . . . . . . . . . . . . . . . . . . . .  8
     3.2   <activelock/> Element  . . . . . . . . . . . . . . . . . . 10
     3.3   <diff/> Element  . . . . . . . . . . . . . . . . . . . . . 10
     3.4   <etag/> Element  . . . . . . . . . . . . . . . . . . . . . 11
     3.5   <href/> Element  . . . . . . . . . . . . . . . . . . . . . 11
     3.6   <propertyupdate/> Element  . . . . . . . . . . . . . . . . 12
   4.  Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
     4.1   Collection Created . . . . . . . . . . . . . . . . . . . . 13
     4.2   Resource Created . . . . . . . . . . . . . . . . . . . . . 14
     4.3   Resource Copied  . . . . . . . . . . . . . . . . . . . . . 16
     4.4   Properties Modified  . . . . . . . . . . . . . . . . . . . 19
     4.5   Resource Locked  . . . . . . . . . . . . . . . . . . . . . 21
     4.6   Resource Modified  . . . . . . . . . . . . . . . . . . . . 23
     4.7   Resource Unlocked  . . . . . . . . . . . . . . . . . . . . 25
     4.8   Resource Deleted . . . . . . . . . . . . . . . . . . . . . 26
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   6.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
   6.1   Normative References . . . . . . . . . . . . . . . . . . . . 27
   6.2   Informative References . . . . . . . . . . . . . . . . . . . 28
       Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 28
       Intellectual Property and Copyright Statements . . . . . . . . 29

















Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 2]
Internet-Draft               WEBDAV-EVENTS                September 2004



1.  Introduction


1.1  Overview


   [WEBDAV] defines a set of extensions to [HTTP] 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 [SMTP] 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, [WEBDAV] 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-CORE].
   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 [XMPP-PUBSUB]




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 3]
Internet-Draft               WEBDAV-EVENTS                September 2004



   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.


1.2  Use Cases


   Several use cases originally motivated this proposal:


   1.  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.
   2.  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.


1.3  Process Flow


   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:


   o  A WebDAV client creates a resource at a WebDAV service.
   o  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.
   o  One or more XMPP entities subscribe to the pubsub node.
   o  A WebDAV client requests completion of a WebDAV operation on the
      resource.
   o  The WebDAV service successfully completes the requested operation.
   o  The WebDAV service sends an appropriate XMPP pubsub request --
      node creation, node deletion, or publish (with payload if
      appropriate) -- to the XMPP pubsub service.
   o  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
   [WEBDAV] and related memos.  The XMPP protocols for the other steps
   are shown in the examples provided below.





Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 4]
Internet-Draft               WEBDAV-EVENTS                September 2004



   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.


1.4  Architecture


   We can visualize the architecture as follows:


        +---------------+
        | WebDAV Client |
        +---------------+
               |
               | [HTTP/1.1 + WebDAV]
               |
        +----------------+
        | WebDAV Service |
        +----------------+
               |
               | [XMPP + Pubsub Extension]
               |
     +---------------------+
     | XMPP Pubsub Service |
     +---------------------+
               |
               | [XMPP + Pubsub Extension]
               |
        +-------------+
        | XMPP Entity |
        +-------------+



1.5  Terminology


   This document inherits terminology from [WEBDAV], [XMPP-CORE], and
   [XMPP-PUBSUB].


   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 [TERMS].


1.6  Discussion Venue


   The authors welcome discussion and comments related to the topics
   presented in this document.  The preferred forum is the




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 5]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <w3c-dist-auth@w3.org> mailing list, for which subscription
   information and archive links are available at <>.


1.7  Acknowledgements


   Thanks to Lisa Dusseault for helpful comments.


2.  Properties


   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.


2.1  Pubsub Notification Property


   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.


   PROPFIND /foo/bar HTTP/1.1
   Host: example.com
   Depth: 1
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx


   <?xml version="1.0" encoding="UTF-8" ?>
   <propfind xmlns="DAV:">
     <prop>
       <notify
         xmlns="urn:ietf:params:xml:ns:webdav-event:prop:notify"/>
     </prop>
   </propfind>


   Then the WebDAV service responds with "true" or "false".




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 6]
Internet-Draft               WEBDAV-EVENTS                September 2004



   HTTP/1.1 207 Multi-Status
   Date: Mon, 27 Sep 2004 19:52:01 GMT
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx


   <?xml version="1.0" encoding="UTF-8" ?>
   <multistatus xmlns="DAV:">
     <response>
       <href>http://example.com/foo/bar</href>
       <propstat>
         <notify
             xmlns="urn:ietf:params:xml:ns:webdav-event:prop:notify">
           true
         </notify>
         <status>HTTT//1.1 200 OK</status>
       </propstat>
     </response>
   </propfind>



2.2  Pubsub Node Property


   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 [XMPP-CORE])
   and the node ID at which notifications are published (in accordance
   with the definition of a pubsub NodeID in [XMPP-PUBSUB]).  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.




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 7]
Internet-Draft               WEBDAV-EVENTS                September 2004



   First, a client queries a specific WebDAV resource regarding this
   property.


   PROPFIND /foo/bar HTTP/1.1
   Host: example.com
   Depth: 1
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx


   <?xml version="1.0" encoding="UTF-8" ?>
   <propfind xmlns="DAV:">
     <prop>
       <node
         xmlns="urn:ietf:params:xml:ns:webdav-event:prop:node"/>
     </prop>
   </propfind>


   Then the WebDAV service responds with the XMPP address of the pubsub
   service along with the specific node ID.


   HTTP/1.1 207 Multi-Status
   Date: Mon, 27 Sep 2004 20:06:38 GMT
   Content-Type: text/xml; charset="utf-8"
   Content-Length: xxxx


   <?xml version="1.0" encoding="UTF-8" ?>
   <multistatus xmlns="DAV:">
     <response>
       <href>http://example.com/foo/bar</href>
       <propstat>
         <node xmlns="urn:ietf:params:xml:ns:webdav-event:prop:node">
           <service>pubsub.example.com</service>
           <nodeid>webdav|http://example.com/foo/bar</nodeid>
         </node>
         <status>HTTT//1.1 200 OK</status>
       </propstat>
     </response>
   </propfind>



3.  Payload Format


3.1  Wrapper Element


   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




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 8]
Internet-Draft               WEBDAV-EVENTS                September 2004



   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:


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='METHOD-NAME'
             resource='RESOURCE-URI'>
       [ OPTIONAL PAYLOAD ELEMENTS ]
     </webdav>


   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:


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='DELETE'
             resource='http://example.com/foo/bar'/>


   The same is true of the UNLOCK operation:


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='UNLOCK'
             resource='http://example.com/foo/bar'/>


   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 [WEBDAV]), and other operations may result in a new
   ETag or output in some other XML format defined in [WEBDAV].  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.




Hildebrand & Saint-Andre    Expires March 29, 2005              [Page 9]
Internet-Draft               WEBDAV-EVENTS                September 2004



3.2  <activelock/> Element


   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).


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='LOCK'
             resource='http://example.com/foo/bar'>
       <activelock xmlns='DAV:'>
         <locktype><write/></locktype>
         <lockscope><exclusive/></lockscope>
         <depth>infinity</depth>
         <owner>
           <href>
             http://jabber.org/people/stpeter.php
           </href>
         </owner>
         <timeout>Second-604800</timeout>
         <lockroot>
           <href>http://example.com/foo/bar</href>
         </lockroot>
       </activelock>
     </webdav>


   Note: A WebDAV service MAY send less information than shown above,
   and for security purposes SHOULD NOT include the <locktoken/> element
   described in [WEBDAV].


3.3  <diff/> Element


   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 [BASE64].  The value of the 'format' attribute specifies
   which diff format is used; possible values include, but are not
   limited to, "gdiff" (see [GDIFF] and "vcdiff" (see [VCDIFF]).


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='PUT'
             resource='http://example.com/foo'>
       <diff xmlns='urn:ietf:params:xml:ns:webdav-event:payload:diff'
             format='gdiff'>
         base64




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 10]
Internet-Draft               WEBDAV-EVENTS                September 2004



       </diff>
     </webdav>


   The <diff/> payload child MAY also be published as a result of a
   successful PATCH operation (see [PATCH]).


3.4  <etag/> Element


   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
   [HTTP].


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='POST'
             resource='http://example.com/foo/bar'>
       <etag xmlns='urn:ietf:params:xml:ns:webdav-event:payload:etag'>
         some-entity-tag
       </etag>
     </webdav>



3.5  <href/> Element


   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.


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='COPY'
             resource='http://example.com/foo'>
       <href xmlns='DAV:'>http://example.com/foo/newbar</href>
     </webdav>



     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='MOVE'
             resource='http://example.com/foo'>
       <href xmlns='DAV:'>http://example.com/foo/newbar</href>
     </webdav>






Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 11]
Internet-Draft               WEBDAV-EVENTS                September 2004



3.6  <propertyupdate/> Element


   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 [WEBDAV].


     <webdav xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
             method='POST'
             resource='http://example.com/foo/bar'>
       <propertyupdate xmlns='DAV:'>
         <set>
           <prop>
             <publish xmlns='http://example.com/ns'>true</publish>
           </prop>
         </set>
       </propertyupdate>
     </webdav>



4.  Examples


   This section currently provides several examples of process flows.
   We assume the following order of operations:


   1.  A new collection "foo" is created at the example.com WebDAV
       service.
   2.  A new resource "bar" is created within the "foo" collection.
   3.  The "bar" resource is copied to the "newbar" resource.
   4.  The properties of the "bar" resource are modified.
   5.  The "bar" resource is locked.
   6.  The "bar" resource is modified.
   7.  The "bar" resource is unlocked.
   8.  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.




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 12]
Internet-Draft               WEBDAV-EVENTS                September 2004



4.1  Collection Created


   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:


   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='mkcol1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <create node='foo'/>
       <configure>
         <x xmlns='jabber:x:data' type='submit'>
           <field type='hidden' var='FORM_TYPE'>
             <value>
               http://jabber.org/protocol/pubsub#node_config
             </value>
           </field>
           <field var='pubsub#node_type'>
             <value>collection</value>
           </field>
         </x>
       </configure>
     </pubsub>
   </iq>


   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
   [XMPP-PUBSUB].  (Note that in accordance with the rules in
   [XMPP-PUBSUB] 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".)













Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 13]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items>
         <item id='webdav|http://example.com/foo'>
           <x xmlns='jabber:x:data' type='result'>
             <field var='FORM_TYPE' type='hidden'>
               <value>
                 http://jabber.org/protocol/pubsub#meta-data
               </value>
             </field>
             <field var='pubsub#creation_date'
                    label='Creation date'>
               <var>2004-09-23T17:23Z</var>
             </field>
             <field var='pubsub#creator' label='Node creator'>
               <var>webdav-service.example.com</var>
             </field>
             <field var='pubsub#type' label='The type of node'>
               <var>urn:ietf:params:xml:ns:webdav-event</var>
             </field>
           </x>
        </items>
     </event>
   </message>



4.2  Resource Created


   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:

















Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 14]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='put1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <create id='bar'/>
       <configure>
         <x xmlns='jabber:x:data' type='submit'>
           <field var='pubsub#collections'>
             <value>foo</value>
           </field>
         </x>
       </configure>
     </pubsub>
   </iq>


   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.


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo'>
         <item id='webdav|http://example.com/foo/bar'>
           <x xmlns='jabber:x:data' type='result'>
             <field var='FORM_TYPE' type='hidden'>
               <value>
                 http://jabber.org/protocol/pubsub#meta-data
               </value>
             </field>
             <field var='pubsub#creation_date'
                    label='Creation date'>
               <var>2004-09-23T17:26Z</var>
             </field>
             <field var='pubsub#creator' label='Node creator'>
               <var>webdav-service.example.com</var>
             </field>
             <field var='pubsub#type' label='The type of node'>
               <var>urn:ietf:params:xml:ns:webdav-event</var>
             </field>
           </x>
        </items>
     </event>
   </message>


   Those informed of the new node may then decide to subscribe to it for




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 15]
Internet-Draft               WEBDAV-EVENTS                September 2004



   pubsub item notifications; we shall assume that the TrackerBot does
   so:


   <iq from='trackerbot@example.com/bot'
       to='pubsub.example.com'
       type='set'
       id='sub1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <subscribe
           node='webdav|http://example.com/foo/bar'
           jid='trackerbot@example.com'/>
     </pubsub>
   </iq>


   The pubsub service then replies with success:


   <iq from='pubsub.example.com'
       to='trackerbot@example.com/bot'
       type='result'
       id='sub1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <entity
           node='webdav|http://example.com/foo/bar'
           jid='trackerbot@example.com'
           affiliation='none'
           subid='123-abc'
           subscription='subscribed'/>
     </pubsub>
   </iq>



4.3  Resource Copied


   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:





Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 16]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='newnode2'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <create id='newbar'/>
       <configure>
         <x xmlns='jabber:x:data' type='submit'>
           <field var='pubsub#collections'>
             <value>foo</value>
           </field>
         </x>
       </configure>
     </pubsub>
   </iq>


   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.


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo'>
         <item id='webdav|http://example.com/foo/newbar'>
           <x xmlns='jabber:x:data' type='result'>
             <field var='FORM_TYPE' type='hidden'>
               <value>
                 http://jabber.org/protocol/pubsub#meta-data
               </value>
             </field>
             <field var='pubsub#creation_date'
                    label='Creation date'>
               <var>2004-09-23T20:22Z</var>
             </field>
             <field var='pubsub#creator' label='Node creator'>
               <var>webdav-service.example.com</var>
             </field>
             <field var='pubsub#type' label='The type of node'>
               <var>urn:ietf:params:xml:ns:webdav-event</var>
             </field>
           </x>
        </items>
     </event>
   </message>


   Those informed of the new node may then decide to subscribe to it for




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 17]
Internet-Draft               WEBDAV-EVENTS                September 2004



   pubsub item notifications; we shall assume that the TrackerBot does
   so:


   <iq from='trackerbot@example.com/bot'
       to='pubsub.example.com'
       type='set'
       id='sub2'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <subscribe
           node='webdav|http://example.com/foo/newbar'
           jid='trackerbot@example.com'/>
     </pubsub>
   </iq>


   The pubsub service then replies with success:


   <iq from='pubsub.example.com'
       to='trackerbot@example.com/bot'
       type='result'
       id='sub2'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <entity
           node='webdav|http://example.com/foo/newbar'
           jid='trackerbot@example.com'
           affiliation='none'
           subid='234-bcd'
           subscription='subscribed'/>
     </pubsub>
   </iq>


   Second, the WebDAV service publishes a COPY event to the pubsub node
   for the "bar" resource.




















Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 18]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='copy1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <publish node='webdav|http://example.com/foo/bar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='COPY'
               resource='http://example.com/foo/bar'>
             <href xmlns='DAV:'>
               http://example.com/foo/newbar
             </href>
           </webdav>
         </item>
       </publish>
     </pubsub>
   </iq>


   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).


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo/bar'>
         <item id='copy-id'>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='COPY'
               resource='http://example.com/foo/bar'>
             <href xmlns='DAV:'>
               http://example.com/foo/newbar
             </href>
           </webdav>
         </item>
        </items>
     </event>
   </message>



4.4  Properties Modified


   Next, a WebDAV client modifies the properties of the "bar" resource
   by means of a PROPPATCH operation.




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 19]
Internet-Draft               WEBDAV-EVENTS                September 2004



   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:


   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='proppatch1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <publish node='webdav|http://example.com/foo/bar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='PROPPATCH'
               resource='http://example.com/foo/bar'>
             <propertyupdate xmlns='DAV:'>
               <set>
                 <prop>
                   <publish xmlns='http://example.com/ns'>
                     true
                   </publish>
                 </prop>
               </set>
             </propertyupdate>
           </webdav>
         </item>
       </publish>
     </pubsub>
   </iq>


   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).
















Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 20]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo/bar'>
         <item id='prop-id'>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='PROPPATCH'
               resource='http://example.com/foo/bar'>
             <propertyupdate xmlns='DAV:'>
               <set>
                 <prop>
                   <publish xmlns='http://example.com/ns'>
                     true
                   </publish>
                 </prop>
               </set>
             </propertyupdate>
           </webdav>
         </item>
        </items>
     </event>
   </message>



4.5  Resource Locked


   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:


















Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 21]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='proppatch1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <publish node='webdav|http://example.com/foo/bar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='LOCK'
               resource='http://example.com/foo/bar'>
             <activelock xmlns='DAV:'>
               <locktype><write/></locktype>
               <lockscope><exclusive/></lockscope>
               <depth>infinity</depth>
               <owner>
                 <href>
                   http://jabber.org/people/stpeter.php
                 </href>
               </owner>
               <timeout>Second-604800</timeout>
               <locktoken>
                 <href>
                   opaquelocktoken:e71d4fae-5dec-22d6-\
                   fea5-00a0c91e6be4
                 </href>
               </locktoken>
               <lockroot>
                 <href>http://example.com/foo/bar</href>
               </lockroot>
             </activelock>
           </webdav>
         </item>
       </publish>
     </pubsub>
   </iq>


   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).











Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 22]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo/bar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='LOCK'
               resource='http://example.com/foo/bar'>
             <activelock xmlns='DAV:'>
               <locktype><write/></locktype>
               <lockscope><exclusive/></lockscope>
               <depth>infinity</depth>
               <owner>
                 <href>
                   http://jabber.org/people/stpeter.php
                 </href>
               </owner>
               <timeout>Second-604800</timeout>
               <locktoken>
                 <href>
                   opaquelocktoken:e71d4fae-5dec-22d6-\
                   fea5-00a0c91e6be4
                 </href>
               </locktoken>
               <lockroot>
                 <href>http://example.com/foo/bar</href>
               </lockroot>
             </activelock>
           </webdav>
         </item>
        </items>
     </event>
   </message>



4.6  Resource Modified


   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:







Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 23]
Internet-Draft               WEBDAV-EVENTS                September 2004



   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='put2'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <publish node='webdav|http://example.com/foo/bar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='PUT'
               resource='http://example.com/foo/bar'>
             <diff
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload:diff'>
               base64
             </diff>
           </webdav>
         </item>
       </publish>
     </pubsub>
   </iq>


   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).


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo/bar'>
         <item id='mod-id'>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='PUT'
               resource='http://example.com/foo/bar'>
             <diff
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload:diff'>
               base64
             </diff>
           </webdav>
         </item>
        </items>
     </event>
   </message>








Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 24]
Internet-Draft               WEBDAV-EVENTS                September 2004



4.7  Resource Unlocked


   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:


   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='unlock1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <publish node='webdav|http://example.com/foo/bar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='UNLOCK'
               resource='http://example.com/foo/bar'/>
         </item>
       </publish>
     </pubsub>
   </iq>


   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).


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo/bar'>
         <item id='unlock-id'>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='UNLOCK'
               resource='http://example.com/foo/bar'/>
         </item>
        </items>
     </event>
   </message>








Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 25]
Internet-Draft               WEBDAV-EVENTS                September 2004



4.8  Resource Deleted


   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:


   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='delete1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <publish node='webdav|http://example.com/foo/newbar'>
         <item>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='DELETE'
               resource='http://example.com/foo/newbar'/>
         </item>
       </publish>
     </pubsub>
   </iq>


   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).


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <items node='webdav|http://example.com/foo/newbar'>
         <item id='delete-id'>
           <webdav
               xmlns='urn:ietf:params:xml:ns:webdav-event:payload'
               method='DELETE'
               resource='http://example.com/foo/newbar'/>
         </item>
        </items>
     </event>
   </message>


   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




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 26]
Internet-Draft               WEBDAV-EVENTS                September 2004



   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:


   <iq type='set'
       from='webdav-service.example.com'
       to='pubsub.example.com'
       id='delete1'>
     <pubsub xmlns='http://jabber.org/protocol/pubsub'>
       <delete id='webdav|http://example.com/foo/newbar'/>
     </pubsub>
   </iq>


   Subscribers will then be notified that the node has been deleted:


   <message from='pubsub.example.com'
            to='trackerbot@example.com'>
     <event xmlns='http://jabber.org/protocol/pubsub#event'>
       <delete id='webdav|http://example.com/foo/newbar'/>
     </event>
   </message>



5.  Security Considerations


   Detailed security considerations for the relevant protocols profiled
   in this memo are given in [WEBDAV], [XMPP-CORE], and [XMPP-PUBSUB].


   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 [XMPP-PUBSUB]; 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.


6.  References


6.1  Normative References


   [BASE64]   Josefsson, S., "The Base16, Base32, and Base64 Data
              Encodings", RFC 3548, July 2003.


   [HTTP]     Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.




Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 27]
Internet-Draft               WEBDAV-EVENTS                September 2004



   [TERMS]    Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.


   [WEBDAV]   Dusseault, L. and J. Crawford, "HTTP Extensions for
              Distributed Authoring - WebDAV RFC2518 bis",
              draft-ietf-webdav-rfc2518bis-06 (work in progress), July
              2004.


   [XMPP-CORE]
              Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", draft-ietf-xmpp-core-24 (work in
              progress), May 2004.


   [XMPP-PUBSUB]
              Millard, P., "Publish-Subscribe", JSF JEP 0060, July 2004.


6.2  Informative References


   [GDIFF]   Hoff, A. and J. Payne, "Generic Diff Format Specification",
             W3C NOTE NOTE-gdiff-19970901, September 1997.


   [PATCH]   Dusseault, L., "Partial Document Changes (PATCH Method) for
             HTTP", draft-dusseault-http-patch-04 (work in progress),
             August 2004.


   [SMTP]    Klensin, J., "Simple Mail Transfer Protocol", RFC 2821,
             April 2001.


   [VCDIFF]  Korn, D., MacDonald, J., Mogul, J. and K. Vo, "The VCDIFF
             Generic Differencing and Compression Data Format", RFC
             3284, June 2002.



Authors' Addresses


   Joe Hildebrand
   Jabber, Inc.


   EMail: jhildebrand@jabber.com



   Peter Saint-Andre
   Jabber Software Foundation


   EMail: stpeter@jabber.org







Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 28]
Internet-Draft               WEBDAV-EVENTS                September 2004



Intellectual Property Statement


   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.


   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.


   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.



Disclaimer of Validity


   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.



Copyright Statement


   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.



Acknowledgment


   Funding for the RFC Editor function is currently provided by the
   Internet Society.





Hildebrand & Saint-Andre    Expires March 29, 2005             [Page 29]