<abstract>This specification defines a Jingle application type for transferring files between two entities. The protocol provides a modular framework that enables the exchange of information about the file to be transferred as well as the negotiation of parameters such as the transport to be used.</abstract>
<remark><p>Initial published version.</p></remark>
</revision>
<revision>
<version>0.0.3</version>
<date>2008-02-29</date>
<initials>psa</initials>
<remark><p>Corrected use of content-replace action; specified that the In-Band Bytestreams transport method is mandatory-to-implement but must have the lowest preference order.</p></remark>
</revision>
<revision>
<version>0.0.2</version>
<date>2008-02-28</date>
<initials>psa</initials>
<remark>Modified negotiation flow to use new content-replace action.</remark>
</revision>
<revision>
<version>0.0.1</version>
<date>2008-01-29</date>
<initials>psa</initials>
<remark>First draft.</remark>
</revision>
</header>
<section1topic='Introduction'anchor='intro'>
<p>&xep0096; defines the current XMPP protocol extension for file transfer. However, that protocol has several drawbacks, most related to the &xep0095; protocol on which it depends:</p>
<ol>
<li>It does not enable a true, bidirectional negotiation; instead, the initiator sets the terms for the file transfer and the receiver either accepts the terms or cancels the negotiation.</li>
<li>It is the only technology in the Jabber/XMPP protocol "stack" that uses <cite>XEP-095: Stream Initiation</cite>. More modern technologies such as voice and video session negotiation use &xep0166;, and it would be helpful if implementors could use the same code for all negotiation use cases.</li>
</ol>
<p>To overcome these drawbacks, this specification defines a file transfer negotiation method that meets the following requirements:</p>
<ul>
<li>Reuse the session negotiation semantics from <cite>XEP-0166</cite>.</li>
<li>Reuse the file description format from <cite>XEP-0096</cite>.</li>
<li>Define a clear upgrade path from <cite>XEP-0096</cite> to this specification.</li>
</ul>
</section1>
<section1topic='How It Works'anchor='protocol'>
<p>This section provides a friendly introduction to Jingle file transfer.</p>
<p>First, the party that wishes to initiate the file transfer determines the receiver's capabilities (via &xep0030; or &xep0115;). In this example, we assume that the receiver supports the following service discovery features (note: these features may not reflect final namespace assignments):</p>
<p>The initiator then sends a Jingle session-initiation request to a potential receiver. The content-type of the request specifies two things:</p>
<ol>
<li>An application type of "urn:xmpp:tmp:jingle:apps:file-transfer" &NSNOTE;. In particular, the <description/> element contains an <offer/> or <request/> element that in turn contains a <file/> element qualified by the existing 'http://jabber.org/protocol/si/profile/file-transfer' namespace from <cite>XEP-0096</cite>.</li>
<li>An appropriate transport method. Because the existing transport methods used in <cite>XEP-0096</cite> (i.e., &xep0065; and &xep0047;) are not yet defined as Jingle transport methods, this specification registers those definitions.</li>
</ol>
<p>In this example, the initiation request specifies a file offer and a transport method of bytestreams (i.e., XEP-065).</p>
<p>The parties would then attempt to negotiate use of the SOCKS5 Bytestreams transport method, as described in <cite>XEP-0065</cite>.</p>
<p>More detailed scenarios follow.</p>
</section1>
<section1topic='Scenarios'anchor='scenarios'>
<section2topic='Fallback'anchor='fallback'>
<p>Currently, <cite>XEP-0096</cite> does not enable the parties to fall back to a second method (e.g., In-Band Bytestreams) if the first method tried (e.g., SOCKS5 Bytestreams) does not work. This problem is addressed by Jingle. Consider the following protocol flow.</p>
<p>Now the parties attempt to negotiate use of SOCKS5 Bytestreams as defined in <cite>XEP-0065</cite>.</p>
<p>However, let us imagine that the SOCKS5 Bytestreams negotiation fails. The initiator or responder can then suggest the use of In-Band Bytestreams by sending a content-replace action. Here we assume that the responder sends a content-replace action including a request for the file originally offered and a transport of IBB.</p>
<p><cite>XEP-0096</cite> enable the initiator to offer more than one transport and for the receiving party to choose its desired transport. This flow can be emulated in Jingle negotiation as follows.</p>
<examplecaption="Initiator sends session-initiate with multiple transports"><![CDATA[
<section2topic='Mandatory to Implement Technologies'anchor='impl-mti'>
<p>All implementations MUST support the In-Band Bytestreams transport method.</p>
</section2>
<section2topic='Preference Order of Transport Methods'anchor='impl-pref'>
<p>An application MAY present transport methods in any order, except that the In-Band Bytestreams method MUST be the lowest preference.</p>
</section2>
<section2topic='Migration from XEP-0096'anchor='impl-migration'>
<p>Support for Jingle file transfer can be determined through discovery of the 'urn:xmpp:tmp:jingle:apps:file-transfer' namespace &NSNOTE;, via either service discovery or entity capabilities. If the initiator knows that the receiver supports Jingle file transfer, it SHOULD attempt negotiation using XEP-0166 rather than XEP-0095.</p>
<p>In order to secure the data stream, implementations SHOULD use encryption methods appropriate to the transport method being used. For details, refer to the specifications for those transport methods.</p>
<p>Until this specification advances to a status of Draft, its associated namespaces shall be:</p>
<ul>
<li>urn:xmpp:tmp:jingle:apps:file-transfer</li>
</ul>
<p>Upon advancement of this specification, the ®ISTRAR; shall issue permanent namespaces in accordance with the process defined in Section 4 of &xep0053;.</p>
<p>The following namespaces are requested, and are thought to be unique per the XMPP Registrar's requirements:</p>
<p>The XMPP Registrar shall include "file-transfer" in its registry of Jingle application formats. The registry submission is as follows:</p>
<code><![CDATA[
<application>
<name>file-transfer</name>
<desc>Jingle sessions for the transfer of a file</desc>
<transport>reliable</transport>
<doc>XEP-xxxx</doc>
</application>
]]></code>
</section2>
<section2topic='Jingle Transport Methods'anchor='registrar-transports'>
<p>The XMPP Registrar shall add to its registry of Jingle transport methods definitions for the reliable transport methods defined in <cite>XEP-0047</cite> and <cite>XEP-0065</cite>. The registry submissions are as follows:</p>
<code><