[Foundation] Call For Arbitration: File Transfer

Dave Smith dizzyd at jabber.org
Mon Aug 25 22:44:22 CDT 2003

On Monday, Aug 25, 2003, at 14:47 America/Denver, Justin Karneges wrote:

>> 3) How do you handle a failure during a stream transfer?
>> REL requires that you try and send the file again and again until it
>> succeeds, or you hit a keep alive limit.
>> SI just stops and the file is not transfered.  It is left up to the 
>> user to
>> resend it.
>> It is simple enough for an author to support automation within their 
>> Client
>> without requiring it in the protocol.
> Could you explain how you plan to automate this?  It has been noted 
> repeatedly
> by Aleksey and myself that SI is not capable of doing this properly.  
> I don't
> see how a council meeting makes the problem magically disappear.

Well, your client sees that the selected stream profile didn't work, so 
A.) Comes up with a new set of alternatives and proposes those
B.) Gives up, since there really is no path between the users suitable 
for file transfer.

I really don't see what's so difficult to understand about this. This 
is an implementation issue, not protocol.

> As I stated in a previous email to standards-jig regarding JEP-105:
> "Maybe I'm dense, but why is this even an SI profile?  It doesn't 
> appear to
> use a stream at all."

I will make no comments as to your relative density -- I'm made out of 
as much water as you.

However, JEP-105 provides a structure for offering a whole series of 
files to a client, and allowing the recipient to know in advance how 
many files, and their sizes are being offered. This permits the 
recipient's client to act intelligently about (what is arguably) a 
single transfer, composed of several "sub" transfers. The alternative 
here would be to generate an SI request per file, without providing any 
information to the recipient's client about how all the SI requests are 


More information about the Members mailing list