[Standards-JIG] Proposed File Transfer JEP Changes
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'
> <file xmlns='http://jabber.org/protocol/si/profile/file-transfer'
> <feature xmlns='http://jabber.org/protocol/feature-neg'>
> <x xmlns='jabber:x:data' type='form'>
> <field var='stream-method' type='list-multi'>
> 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
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
> 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
(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.
Jabber Software Foundation
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards