1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-12-21 23:28:51 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@777 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2007-04-19 15:41:48 +00:00
parent debb94728c
commit d887f7b0a8

View File

@ -7,7 +7,7 @@
<xep>
<header>
<title>WebDAV File Transfers</title>
<abstract>This document a method for completing Jabber file transfers using WebDAV.</abstract>
<abstract>This document specifies a method for completing file transfers between XMPP entities using WebDAV.</abstract>
&LEGALNOTICE;
<number>0129</number>
<status>Experimental</status>
@ -23,13 +23,13 @@
<supersedes/>
<supersededby/>
<shortname>TO BE ASSIGNED</shortname>
&dizzyd;
&stpeter;
&dizzyd;
<revision>
<version>0.3</version>
<date>2007-02-02</date>
<date>2007-04-19</date>
<initials>psa</initials>
<remark><p>Incorporated WedDAV feedback.</p></remark>
<remark><p>Corrected to reflect changes to XEP-0070; incorporated WedDAV feedback.</p></remark>
</revision>
<revision>
<version>0.2</version>
@ -45,8 +45,8 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xep0096; 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 &rfc2518; (see also the revision-in-progress, &rfc2518bis;).</p>
<p>The use case in which the recipient is offline is the main driver behind this document. 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.</p>
<p>&xep0096; 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 their 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 &rfc2518; (see also the revision-in-progress, &rfc2518bis;).</p>
<p>The use case in which the recipient is offline is the main motivation for this document. 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.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the following requirements:</p>
@ -61,7 +61,7 @@
<section1 topic='Protocol Flow' anchor='protocol'>
<p>The client SHOULD attempt to PUT the file on the server. <note>Alternatively, the client MAY first attempt one or more HEAD requests to determine a unique URL.</note> The PUT request MUST include an "If-None-Match" header as well as an "Authorization" header that specifies appropriate authentication information.</p>
<example caption='Initial PUT Request'><![CDATA[
PUT /uniqueurl HTTP/1.1
PUT /missive.html HTTP/1.1
Host: files.shakespeare.lit
Authorization: Basic cm9tZW9AbW9udGFndWUubmV0
If-None-Match: *
@ -70,18 +70,18 @@
[body omitted]
]]></example>
<p>Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. 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.</p>
<p>Prior to storing the file, the server MUST verify the user's authentication credentials via any supported method. 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 perform operations such as DELETE, MOVE, and PROPPATCH.</p>
<example caption='HTTP OK'><![CDATA[
HTTP/1.1 200 OK
Date: Thu, 18 Dec 2003 15:01:20 GMT
]]></example>
<p>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.</p>
<p>In the absence of any other authorization method (e.g., &rfc3744; or &saml;) in use by the deployed WebDAV server, the client SHOULD 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.</p>
<example caption='PROPPATCH Request'><![CDATA[
PROPPATCH /uniqueurl HTTP/1.1
PROPPATCH /missive.html HTTP/1.1
Host: files.shakespeare.lit
Authorization: x-xmpp-auth jid=[base64 encoded jid]
Authorization: Basic cm9tZW9AbW9udGFndWUubmV0
Content-Type: text/xml
Content-Length: 176
Content-Length: 243
<propertyupdate xmlns='DAV:'>
<set>
@ -93,11 +93,12 @@
</jidlist>
</prop>
</set>
</propertyupdate>]]></example>
</propertyupdate>
]]></example>
<p>Note: The semantics of the JID list defined above are:</p>
<ul>
<li>If a JID is a bare JID (no resource), any fully-qualified form of that JID may access this resource (in the example above, this means that any resource of juliet@capulet.com may access this URL).</li>
<li>If a JID includes a resource identifier, only that specific JID may access this URL (in the example above, this means that only the JID benvolio@montague.net/home may access this URL; benvolio@montague.net/other may NOT).</li>
<li>If a JID includes a resource identifier, only that specific JID may access this URL (in the example above, this means that only the JID benvolio@montague.net/home may access this URL; benvolio@montague.net/other may not).</li>
<li>If both a full JID and a bare JID are specified in a single JID list, the bare JID takes precedence.</li>
</ul>
<p>The server responds when the properties have been updated. This is typically a 207 (MultiPart) response, which means that the body can contain multiple status codes, as shown in the following example.</p>
@ -109,7 +110,7 @@
<multistatus xmlns='DAV:'>
<response>
<href>http://files.shakespeare.lit/uniqueurl</href>
<href>http://files.shakespeare.lit/missive.html</href>
<propstat>
<prop><jidlist xmlns='http://www.xmpp.org/extensions/xep-0129#ns'/></prop>
<status>HTTP/1.1 200 OK</status>
@ -117,46 +118,41 @@
</response>
</multistatus>
]]></example>
<p>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 &xep0066; to ensure backwards compatibility. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p>
<p>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, encapsulated via &xep0066;. (The example below shows the file being sent to multiple users using the &xep0033; protocol.)</p>
<example caption='Sender Generates XMPP Message with URL'><![CDATA[
<message from='romeo@montague.net/pda' to='multicast.jabber.org'>
<addresses xmlns='http://jabber.org/protocol/address'>
<address type='to' jid='juliet@capulet.com/chamber'/>
<address type='to' jid='juliet@capulet.com'/>
<address type='to' jid='benvolio@montague.net/home'/>
<address type='cc' jid='mercutio@capulet.com/pda'/>
<address type='cc' jid='mercutio@capulet.com'/>
</addresses>
<x xmlns='jabber:x:oob'>
<url>http://files.shakespeare.lit/uniqueurl</url>
<url>http://files.shakespeare.lit/missive.html</url>
</x>
</message>
]]></example>
<p>When the target recipients have received the message, they may then perform an HTTP GET to download the file (the following request is from juliet@capulet.com).</p>
<example caption='Recipient GET Request'><![CDATA[
GET /uniqueurl HTTP/1.1
GET /missive.html HTTP/1.1
Host: files.shakespeare.lit
Authorization: Basic anVsaWV0QGNhcHVsZXQuY29t
Authorization: Digest username="juliet@capulet.com",
realm="xmpp",
nonce="ec2cc00f21f71acd35ab9be057970609",
uri="missive.html",
qop=auth,
nc=00000001,
cnonce="0a4f113b",
response="6629fae49393a05397450978507c4ef1",
opaque="5ccc069c403ebaf9f0171e9517f40e41"
]]></example>
<p>The server then checks to ensure that the provided JID is on the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:</p>
<p>The server then checks to ensure that the provided JID was specified via the jidlist property. If not, the server MUST return an HTTP 403 (Forbidden) error; if so, the server attempts to authorize the user via &xep0070;:</p>
<example caption='Confirmation Request Sent via Message'><![CDATA[
<message type='normal'
from='files.shakespeare.lit'
to='juliet@capulet.com'>
<thread>e0ffe42b28561960c6b12b944a092794b9683a38</thread>
<body>
Someone (maybe you) has requested the following file:
https://files.shakespeare.lit:9345/missive.html.
The transaction identifier is:
a7374jnjlalasdf82
If you wish to confirm the request, please reply
to this message by typing "OK". If not, please
reply with "No".
</body>
<confirm xmlns='http://jabber.org/protocol/http-auth'
id='a7374jnjlalasdf82'
id='0a4f113b'
method='GET'
url='https://files.shakespeare.lit:9345/missive.html'/>
</message>
@ -171,8 +167,8 @@
[body omitted]
]]></example>
</section1>
<section1 topic='Discovery' anchor='disco'>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" (see <link url='#ns'>Protocol Namespaces</link>). An example of the discovery flow is shown below.</p>
<section1 topic='Determining Support' anchor='disco'>
<p>In order to discover a WebDAV server that supports this protocol, a client SHOULD use &xep0030;. Support for this protocol MUST be advertised by means of a service discovery feature named "http://www.xmpp.org/extensions/xep-0129.html#ns" &NSNOTE;. An example of the discovery flow is shown below.</p>
<example caption='Client Discovers Services'><![CDATA[
<iq from='romeo@shakespeare.lit/home'
id='disco1'
@ -231,19 +227,17 @@
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://www.xmpp.org/extensions/xep-0186.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0186.html#ns'
targetNamespace='http://www.xmpp.org/extensions/xep-0129.html#ns'
xmlns='http://www.xmpp.org/extensions/xep-0129.html#ns'
elementFormDefault='qualified'>
<xs:element name='invisible' type='empty'/>
<xs:element name='visible' type='empty'/>
<xs:simpleType name='empty'>
<xs:restriction base='xs:string'>
<xs:enumeration value=''/>
</xs:restriction>
</xs:simpleType>
<xs:element name='jidlist'>
<xs:complexType>
<xs:sequence minOccurs='0' maxOccurs='unbounded'>
<xs:element name='jid' type='xs:string'/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
]]></code>