JEP-0129: WebDAV File Transfers

This JEP specifies best practices for completing Jabber file transfers using WebDAV.


WARNING: This Informational JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the best practice or protocol profile described herein is encouraged in exploratory implementations, although production systems should not deploy implementations of this protocol until it advances to a status of Draft.


JEP Information

Status: Experimental
Type: Informational
Number: 0129
Version: 0.2
Last Updated: 2004-04-13
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, RFC 2518, JEP-0030, JEP-0066, JEP-0070
Supersedes: None
Superseded By: None
Short Name: webdav-filexfer

Author Information

Dave Smith

Email: dizzyd@jabber.org
JID: dizzyd@jabber.org

Peter Saint-Andre

Email: stpeter@jabber.org
JID: stpeter@jabber.org

Legal Notice

This Jabber Enhancement Proposal is copyright 1999 - 2004 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.php>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).

Discussion Venue

The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.

Given that this JEP normatively references IETF technologies, discussion on the JSF-IETF list may also be appropriate (see <http://mail.jabber.org/mailman/listinfo/jsf-ietf> for details).

Relation to XMPP

The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core and XMPP IM specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocols defined in this JEP have been developed outside the Internet Standards Process and are to be understood as extensions to XMPP rather than as an evolution, development, or modification of XMPP itself.

Conformance Terms

The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.


Table of Contents

1. Introduction
2. Requirements
3. Terminology
3.1. HTTP Terms
4. Discovery
5. Protocol Flow
6. Security Considerations
7. IANA Considerations
8. Jabber Registrar Considerations
Notes
Revision History


1. Introduction

File Transfer [1] defines mechanisms for transferring files between Jabber users, and defines the preferred approach for file transfers in Jabber applications. Unfortunately, the mechanisms defined therein require that both the sender and recipient be online at the same time. However, sometimes it is desirable for the sender to initiate a file transfer while the recipient is offline. One way to make this possible is for the sender to upload the file to a unique URL, then inform the recipient of the URL. The sender could do this by uploading the file to his or her own web server, but not everyone has their own web server. Fortunately, there is a well-defined protocol for such file management operations: a set of HTTP extensions known as WebDAV and defined in RFC 2518 [2].

The use case in which the recipient is offline is the main driver behind this JEP. Another WebDAV use case presents itself in environments that use, or even require, WebDAV for file transfers using other protocols (e.g., files attached to email messages). The usual rationale for such deployments is virus-checking: the file is put onto the WebDAV server (either by an end-user or a script that, for example, strips attached files off email messages) and then checked for viruses; only after the virus check successfully completes is the recipient allowed to retrieve the file. A further benefit of such deployments is that it enables the sender to provide the file to multiple recipients. Thus the approach defined herein provides the added benefit of being usable in generic WebDAV environments as well.

2. Requirements

This JEP addresses the following requirements:

  1. Enable file transfers when recipient is offline.
  2. Use WebDAV for file puts and gets.

3. Terminology

3.1 HTTP Terms

This JEP inherits terms from RFC 2518, RFC 2616 [3], and RFC 2617 [4].

4. Discovery

In order to discover a WebDAV server that supports this protocol, a client SHOULD use Service Discovery [5]. Support for this protocol MUST be advertised by means of a service discovery feature named "http://jabber.org/protocol/webdav-filexfer". An example of the discovery flow is shown below.

Example 1. Client Discovers Services

<iq from='romeo@shakespeare.lit/home'
    id='disco1'
    to='shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#items'/>
</iq>

<iq from='shakespeare.lit'
    id='disco1'
    to='romeo@shakespeare.lit/home'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#items'>
    ...
    <item jid='files.shakespeare.lit'/>
    ...
  </query>
</iq>
  

Example 2. Client Queries Service Regarding Supported Features

<iq from='romeo@shakespeare.lit/home'
    id='disco2'
    to='files.shakespeare.lit'
    type='get'>
  <query xmlns='http://jabber.org/protocol/disco#info'/>
</iq>

<iq from='files.shakespeare.lit'
    id='disco2'
    to='romeo@shakespeare.lit/home'
    type='result'>
  <query xmlns='http://jabber.org/protocol/disco#info'>
    ...
    <feature var='http://jabber.org/protocol/http-auth'/>
    <feature var='http://jabber.org/protocol/webdav-filexfer'/>
    ...
  </query>
</iq>
  

The user now knows that the "files.shakespeare.lit" service supports this protocol.

5. Protocol Flow

The client MUST generate a unique URL and execute an HTTP HEAD request to see if that URL exists; this action SHOULD be repeated until the WebDAV server returns a 404 Not Found.

  HEAD /uniqueurl HTTP/1.1
  Host: files.shakespeare.lit
  

Because the WebDAV server supports Authenticating HTTP Requests via Jabber [6], the initial request fails (since the user did not provide Jabber authentication).

  HTTP/1.1 401 Unauthorized
  WWW-Authenticate: x-xmpp-auth realm=xmpp
  

In this case, the client then re-requests the HEAD with the appropriate credentials. Of course, the client could have avoided this by just providing the Authorization header on the initial request.

  HEAD /uniqueurl HTTP/1.1
  Host: files.shakespeare.lit
  Authorization: x-xmpp-auth jid=[base64 encoded jid]
  

Upon receipt of the HEAD request, the server then proceeds to verify the request using the x-xmpp-auth mechanism defined in JEP-0070. If the verification successfully completed, the server MAY cache further operations on this particular URL for the duration of the HTTP connection. It is recommended that clients keep the HTTP connection open, in accordance with HTTP/1.1 semantics.

In the "happy" path, the server responds that the requested URL was not found.

  HTTP/1.1 404 Not Found
  Date: Thu, 18 Dec 2003 15:00:00 GMT
  

Now the client can PUT the file on the server, with the unique URL. To protect against someone else using the same URL in the timeframe between the HEAD and the PUT, the client MUST include an If-None-Match:* header to ensure that the server will not allow another URL to be overwritten.

  PUT /uniqueurl HTTP/1.1
  Host: files.shakespeare.lit
  Authorization: xmpp-auth (base64 encoded jid)
  If-None-Match: *
  Content-Length: xxx
  Content-Type: text/html

  [body omitted]
  

Prior to storing the file, the server MUST verifies the user's authorization (as detailed above). When the file is stored, the server also MUST set the owner "live" property to ensure that only the user that originally posted this file is allowed to modify the file in any way. Other users MAY be allowed to see properties and retrieve the file (upon authentication) but MUST NOT be able to DELETE, MOVE, PROPPATCH, etc.

  HTTP/1.1 200 OK
  Date: Thu, 18 Dec 2003 15:01:20 GMT
  

In the absence of any other authorization method (e.g., SAML) in use by the deployed WebDAV server, the client MUST perform a PROPPATCH request to set the list of Jabber IDs authorized to retrieve this file, and the server MUST NOT allow access until this configuration is completed.

  PROPPATCH /uniqueurl HTTP/1.1
  Host: files.shakespeare.lit
  Authorization: x-xmpp-auth jid=[base64 encoded jid]
  Content-Type: text/xml
  Content-Length: 176

  <propertyupdate xmlns='DAV:'>
    <set>
      <prop>
	<jidlist xmlns='jabberjidlisturl'>
	  <jid>juliet@capulet.com</jid>
	  <jid>benvolio@montague.net/home</jid>
	  <jid>mercutio@capulet.com</jid>
	</jidlist>
      </prop>
    </set>
  </propertyupdate>

Note: The semantics of the JID list defined above are:

The server responds when the properties have been updated. The book "WebDAV: Next-Generation Collaborative Web Authoring" (Prentice Hall, 2004) suggests that this is typically a 207 (MultiPart) response, which means that the body can contain multiple status codes, as shown in the following example.

  HTTP/1.1 207 MultiPart Response
  Date: Thu, 18 Dec 2003 15:03:20 GMT
  Content-Type: text/xml; charset=UTF-8
  Content-Length: 211

  <multistatus xmlns='DAV:'>
    <response>
      <href>http://files.shakespeare.lit/uniqueurl</href>
      <propstat>
	<prop><jidlist xmlns='jabberjidlisturi'/></prop>
	<status>HTTP/1.1 200 OK</status>
      </propstat>
    </response>
  </multistatus>
  

Now that the file is available via WebDAV and the client has specified what Jabber IDs may access the URL, the sender sends a message to the target user(s) containing the URL of the file, encoded using Out-of-Band Data [7] to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the Extended Stanza Addressing [8] protocol.)

  <message to='multicast.jabber.org'>
   <addresses xmlns='http://jabber.org/protocol/address'>
       <address type='to' jid='juliet@capulet.com/chamber'/>
       <address type='to' jid='benvolio@montague.net/home'/>
       <address type='cc' jid='mercutio@capulet.com/pda'/>
   </addresses>
    <x xmlns='jabber:x:oob'>
      <url>http://files.shakespeare.lit/uniqueurl</url>
    </x>
  </message>
  

When the target recipients have received the message, they may then perform an HTTP GET to download the file.

  GET /uniqueurl HTTP/1.1
  Host: files.shakespeare.lit
  Authorization: xmpp-auth (base64 encoded JID; juliet@capulet.com)
  

The server then checks to ensure that the provided JID is on the jidlist property, and then authorizes the user via JEP-0070; if a JID not on the jidlist attempts to access the file, the server MUST return an HTTP 403 (Forbidden) error. On completion, the server then allows the file to be retrieved.

  HTTP/1.1 200 OK
  Date: Thu, 18 Dec 2003 18:00:00 GMT
  Content-Type: text/html
  Content-Length: xxx

  [body omitted]
  

6. Security Considerations

See RFC 2518, XMPP Core, and JEP-0070 for security considerations related to those protocols, which are used by the profile defined herein. The initiating client MUST ensure that appropriate access controls are specified, normally by performing a PROPPATCH request to set the list of Jabber IDs authorized to retrieve the file. The server MUST NOT allow access to the file until access controls have been specified. In addition, the server MUST NOT allow access to the file by any unauthorized entity.

7. IANA Considerations

This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [9].

8. Jabber Registrar Considerations

Upon advancement of this JEP to a status of Active, the Jabber Registrar [10] shall add the string "http://jabber.org/protocol/webdav-filexfer" to its registry of service discovery features.


Notes

1. JEP-0096: File Transfer <http://www.jabber.org/jeps/jep-0096.html>.

2. RFC 2518: HTTP Extensions for Distributed Authoring -- WEBDAV <http://www.ietf.org/rfc/rfc2518.txt>.

3. RFC 2616: Hypertext Transport Protocol -- HTTP/1.1 <http://www.ietf.org/rfc/rfc2616.txt>.

4. RFC 2617: HTTP Authentication: Basic and Digest Access Authentication <http://www.ietf.org/rfc/rfc2617.txt>.

5. JEP-0030: Service Discovery <http://www.jabber.org/jeps/jep-0030.html>.

6. JEP-0070: Authenticating HTTP via Jabber <http://www.jabber.org/jeps/jep-0070.html>.

7. JEP-0066: Out of Band Data <http://www.jabber.org/jeps/jep-0066.html>.

8. JEP-0033: Extended Stanza Addressing <http://www.jabber.org/jeps/jep-0033.html>.

9. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.

10. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.


Revision History

Version 0.2 (2004-04-13)

Added information about service discovery. (psa)

Version 0.1 (2004-03-12)

Initial version. (psa)


END