Defined file description format separate from XEP-0096; modified the checksum format to reuse the <hashes/> element from XEP-0300; removed the 'urn:xmpp:jingle:apps:file-transfer:info:2' namespace by putting all elements into the 'urn:xmpp:jingle:apps:file-transfer:3' namespace; incremented namespace version from 2 to 3.
To overcome these drawbacks, this specification defines a file transfer negotiation method that meets the following requirements:
Jingle file transfer is only as reliable as the transports on which it depends. In particular, SOCKS5 Bytestreams ("S5B") does not always result in NAT or firewall traversal. To work around that problem, this specification requires all implementations to support as a fallback mechanism In-Band Bytestreams ("IBB"), which usually results in a successful (if slow) file transfer.
@@ -156,13 +162,13 @@First, the party that wishes to initiate the file transfer determines the responder's capabilities (via &xep0030; or &xep0115;). Here we assume that the responder supports the following service discovery features:
The initiator then sends a Jingle session-initiation request to a potential responder. The content-type of the request specifies two things:
Note: All attributes of the <file/> element are defined in XEP-0096, not in this specification.
@@ -200,15 +206,17 @@ Initiator Responder initiator='romeo@montague.lit/orchard' sid='851ba2'>Note: Inclusion of the <range/> child of the <file/> element indicates that the initiatior supports ranged transfers as described below under Ranged Transfers.
+Note: As in XEP-0096, inclusion of the <range/> child of the <file/> element indicates that the initiatior supports ranged transfers as described below under Ranged Transfers.
Note: Computing the hash of the file before sending it can slow down the process of file transfer, since the sending application needs to process the file twice. The sender might prefer to send the hash after the file transfer has begun, using a transport-info message as described under Communicating the Hash.
The responder immediately acknowledges receipt of the Jingle session-initiate.
At any time during the lifetime of the file transfer session, the hosting entity (i.e., the entity where the file resides) can communicate the hash of the file to the receiving entity. This is done by sending a session-info message containing a <hash/> element qualified by the 'urn:xmpp:jingle:apps:file-transfer:info:2' namespace. The XML character data of this <hash/> element has the same meaning as the 'hash' attribute of the <file/> element qualified by the 'http://jabber.org/protocol/si/profile/file-transfer' namespace from XEP-0096; that is, it is a checksum of the file contents produced in accordance with the hashing function specified by the 'algo' attribute, which MUST be one of the functions listed in the &ianahashes;. For historical reasons and for backward-compatibility with XEP-0096, the 'algo' attribute defaults to a value of "md5".
+At any time during the lifetime of the file transfer session, the hosting entity (i.e., the entity where the file resides) can communicate the checksum of the file to the receiving entity. This is done by sending a session-info message containing a <checksum/> element qualified by the 'urn:xmpp:jingle:apps:file-transfer:3' namespace, which in turn contains a <file/> element that MUST at least contain a child element of <hashes/> qualified by the 'urn:xmpp:hashes:0' namespace and MAY contain other elements qualified by the 'urn:xmpp:jingle:apps:file-transfer:3' namespace (e.g. <name/> and <date/>). Each <hash/> child of the <hashes/> element contains a checksum of the file contents produced in accordance with the hashing function specified by the 'algo' attribute, which MUST be one of the functions listed in the &ianahashes;.
If the entity that hosts a file has advertised its existence (or if a previous file transfer attempt has failed and the receiver would like to initiate another attempt), the entity that wishes to receive the file can "pull" the file from the hosting entity. This is done by sending a Jingle session-initiate to the hosting entity, including a &DESCRIPTION; element qualified by the 'urn:xmpp:jingle:apps:file-transfer:2' namespace and containing a <request/> element that defines the requested file.
+If the entity that hosts a file has advertised its existence (or if a previous file transfer attempt has failed and the receiver would like to initiate another attempt), the entity that wishes to receive the file can "pull" the file from the hosting entity. This is done by sending a Jingle session-initiate to the hosting entity, including a &DESCRIPTION; element qualified by the 'urn:xmpp:jingle:apps:file-transfer:3' namespace and containing a <request/> element that defines the requested file.
An application MAY present transport methods in any order, except that the Jingle In-Band Bytestreams Transport Method MUST be the lowest preference.
Support for Jingle file transfer can be determined through discovery of the 'urn:xmpp:jingle:apps:file-transfer:2' namespace &VNOTE;, via either service discovery (XEP-0030) or entity capabilities (XEP-0115). If the initiator knows that the responder supports Jingle file transfer, it SHOULD first attempt negotiation using Jingle rather than Stream Initiation.
+Support for Jingle file transfer can be determined through discovery of the 'urn:xmpp:jingle:apps:file-transfer:3' namespace &VNOTE;, via either service discovery (XEP-0030) or entity capabilities (XEP-0115). If the initiator knows that the responder supports Jingle file transfer, it SHOULD first attempt negotiation using Jingle rather than Stream Initiation.
This specification defines the following XML namespace:
Upon advancement of this specification from a status of Experimental to a status of Draft, the ®ISTRAR; shall add the foregoing namespace to the registry located at &NAMESPACES;, as described in Section 4 of &xep0053;.
-
@@ -674,42 +701,33 @@ Initiator Responder
-
-
-
-
-
-
- ]]>
-
-
-
-
-
-
-
+
+
+
+
+
+
+
- ]]>
- Thanks to Diana Cionoiu, Olivier Crête, Justin Karneges, Steffen Larsen, Yann Leboulanger, Marcus Lundblad, Joe Maissel, Robert McQueen, Ali Sabil, Sjoerd Simons, Will Thompson, Matthew Wild, and Jiří Zárevúcky for their feedback.
+Thanks to Diana Cionoiu, Olivier Crête, Waqas Hussain, Justin Karneges, Steffen Larsen, Yann Leboulanger, Marcus Lundblad, Robert McQueen, Joe Maissel, Glenn Maynard, Ali Sabil, Sjoerd Simons, Will Thompson, Matthew Wild, and Jiří Zárevúcky for their feedback.