[Foundation] Call For Arbitration: File Transfer
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
>> without requiring it in the protocol.
> Could you explain how you plan to automate this? It has been noted
> 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