[Standards-JIG] Proposed File Transfer JEP Changes

Peter Saint-Andre stpeter at jabber.org
Mon Jul 31 22:35:01 UTC 2006

These modifications seem mostly reasonable to me. Comments below.

On 2006-03-07 (!), Alex Wenckus wrote:

> While implementing file transfer in Spark, we found two possible areas
> for improvement in the JEPs:
> 1) Stream mechanism fail-over from SOCKS5 to IBB. 
> Few clients implement IBB yet, but it's a great way to ensure that file
> transfers never fail. Unfortunately, clients have to choose either
> SOCKS5 or IBB when negotiating file transfer, but not both. It would be
> much better if clients could try SOCKS5 first and then switch over to
> IBB if SOCKS5 failed (due to firewall restrictions, etc). Two changes to
> the JEP are required for this to work:
>  a) A recipient must be able to reply back to a file transfer request
> that they'll accept both IBB and SOCKS5 as file transfer mechanisms.
> That means changing the "stream-method" data-form field from list-single
> to list-multi as in the following example:
> <iq type='set' id='offer1' to='receiver at jabber.org/resource'>
>   <si xmlns='http://jabber.org/protocol/si' 
>       id='a0'
>       mime-type='text/plain'
>       profile='http://jabber.org/protocol/si/profile/file-transfer'>
>     <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
>           name='test.txt'
>           size='1022'/>
>     <feature xmlns='http://jabber.org/protocol/feature-neg'>
>       <x xmlns='jabber:x:data' type='form'>
>         <field var='stream-method' type='list-multi'>
> <option><value>http://jabber.org/protocol/bytestreams</value></option>
>           <option><value>http://jabber.org/protocol/ibb</value></option>
>         </field>
>       </x>
>     </feature>
>   </si>
> </iq>
> This change is backwards compatible in our testing -- all the clients
> we've seen ignore the actual data-form type and just send back a single
> reply.

I don't see any problems with doing that.

>  b) Add commentary to the JEP about how fail-over from one mechanism to
> another can occur. Our suggestion is that if a client replies that both
> SOCKS5 and IBB are acceptable (via list-multi reply), then the sender
> will try SOCKS5 first. 

Or try the method that's listed first? But I agree that SOCKS5 should be
preferred over IBB.

> As soon as that fails (for example, no adequate
> stream host), the sender will immediately start an IBB transfer by
> sending the initial IBB packet. This change is backwards compatible
> since no current client (except Spark) would send a list-multi reply
> indicating support for both SOCKS5 and IBB. 

I suppose that's OK if IBB is always considered to be the fallback, but
it seems potentially problematic if there are more than two options --
e.g., what is the order of preference for 3 or 4 methods? Is it better
to send an IQ-result or IQ-error and then offer other options (with a
feature-negotiation form)?

> 2) Improved byte stream security. 
> Server administrators may wish to configure that all file transfers
> happen through a trusted proxy that performs virus scanning, logging,
> etc. Let's consider the virus scanning case. From a security
> perspective, we know that we should never trust the other party.
> Therefore, the list of SOCKS5 StreamHosts sent by file transfer
> initiator can't be trusted (they may allow viruses through). The only
> "trusted" StreamHost in this case will be the proxy operating on the
> recipient's server that has virus scanning enabled.
> The JEP currently says that a recipient must pick a StreamHost from
> among those offered by the initiator. In the case above, unless both the
> initiator and recipient are on the same server then it's not likely that
> file transfer can work since the initiator won't send the trusted proxy
> as an option. Our proposed change is that the recipient can ignore the
> list of StreamHosts sent by the initiator, connect to it's own trusted
> proxy, then notify the initiator that it's connected to that proxy. This
> would mean changing the language in section 4.6 of JEP-0065. Error cases
> would also likely need to be added to section 4.8 since there's no
> guarantee that the connection by the initiator to the proxy will work.

I agree that the current model is less than perfect. Right now, the file
transfer occurs on the initiator's terms, but I might want or need to
use *my* proxy or streamhost, not yours (e.g., because of corporate
policy that incoming files need to be checked for viruses). I see two
potential approaches:

(1) Initiator tells recipient that it has a file to send and recipient
provides the list of streamhosts.

(2) Initiator provides file info and streamhost options and recipient
(potentially) replies with alternate streamhost.

I think (2) requires fewer changes to JEP-0065 so it seems preferable on
that score. But I need to look at the protocol flows some more to see if
that approach is workable.


Peter Saint-Andre
Jabber Software Foundation

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060731/7436b6bf/attachment.bin>

More information about the Standards mailing list