The reasoning behind creating a FT:4 was to leverage the core semantics of 
Jingle versus continuing to reinvent them inside of FT to solve some of the 
remaining open items in the FT:3 spec.

(The idea here being that a general Jingle session management implementation 
should have a well lit path for how to use its existing session management 
tools & data to support file transfer.)


Thus, instead of a bundle of files inside a single Jingle Content, there is a 
separate Content per file. That solves the unresolved issues in FT:3 about how 
to add (and remove!) additional files to the transfer session while it is in 
progress. In FT:4, we use the standard Jingle content-* actions. A nice side 
effect is that it means that the files do not need to wait for each other to 
download over a single connection, the data can be sent in parallel via 
multiple connections.

However, in the process of editing and creating FT:4, the <request/> and 
<offer/> wrappers were removed, which appears to have removed the ability to 
request a file, but that case is still doable with FT:4. It now requires using 
core Jingle semantics instead of something inside FT itself. Namely, Jingle 
Contents may specify which side of the session is supposed to send data. This 
is an example of requesting files using FT:4


<iq to="[email protected]" id="ft4" type="set">
  <jingle xmlns="urn:xmpp:jingle:1" action="session-initiate" 
sid="jrk2o4oi24i3u24o">
    <content name="file-request-1" creator="initiator" senders="responder">
      <description xmlns="urn:xmpp:jingle:apps:file-transfer:4">
        <file>
          <hash xmlns="urn:xmpp:hashes:1" 
algo="sha-1">65ea0164c91de2197956ed143099b90ff37d699e</hash>
          <name>test.txt</name>
          <range/>
        </file>
      </description>
    </content>
    <content name="file-request-2" creator="initiator" senders="responder">
      <description xmlns="urn:xmpp:jingle:apps:file-transfer:4">
        <file>
          <hash xmlns="urn:xmpp:hashes:1" 
algo="sha-1">da39a3ee5e6b4b0d3255bfef95601890afd80709</hash>
          <name>for-good-measure.txt</name>
          <range/>
        </file>
      </description>
    </content>
  </jingle>
</iq>


(Likewise for transfer offers, the Content should include `senders="initiator"` 
to indicate as such.)



I'm currently writing up patches to submit as a PR to add a section covering 
requesting files and the use of the content senders attribute, along with some 
additional examples and editorial fixes.


- Lance

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to