[standards-jig] Re: [Council] File Xfer Call for Arbitration

Alexey Shchepin alexey at sevcom.net
Sat Jul 19 20:01:41 UTC 2003


Hello, Ryan!

On Thu, 17 Jul 2003 17:47:40 -0500, you said:

 RE> We need to come to a final consensus for the file transfer debate and
 RE> issue our "ruling".

 RE> The base differences between Justin's and Thomas' protocols are:

 RE> 1) Profiles vs. Custom namespace for each application.

Profiles also require separate namespace for each profile.

 RE> 2) Auto fail over vs Restarting a stream.


 RE> I would like to start this off by telling you all about our experience
 RE> with Thomas' Stream Initiation(95) at OSCON this year.  Peter Millard,
 RE> Dave Smith, and myself worked to get an implementation of SI and the File
 RE> Transfer Profile(96) up and running.  After much work of adding support
 RE> for all of the required JEPS (disco, fneg, bytestreams, etc...) We were
 RE> able to easily get the SI(95) stuff hooked up and working. Exodus
 RE> currently supports this, as does an upcoming release of Net::Jabber and
 RE> some Perl command line utilities that I wrote.

 RE> The interesting part about SI(95) is the profiles.  It allows you to send
 RE> enough meta-data and stream choices that in one action you can accept and
 RE> initiate the stream.

Are you sure that all applications that will require stream initiation can
exchange enough meta-data in _one_ step?

 RE> This helps cut down on the number of steps in the flow chart for sending
 RE> files.  I was also able to create a Tree Transfer(105)(pending) profile
 RE> for sending someone a directory of files.  Each file is then sent using
 RE> pre negotiated stream ids and FT(96).

 RE> While this may be a pointless feature for some people, profiles make it
 RE> very easy to use the same flow for doing any stream initiation, instead of
 RE> having to create a custom one for each new application of the stream.

But anyway you need to create custom profiles for each application, so from this
point both protocols are equivalent.

To make it more clear: with profiles generic iq exchange looks like this:

PROFILES1:
<iq type='set'>
  <want to transfer/>
  <transfer protocol negotiaion/>
</iq>

PROFILES2:
<iq type='result'>
  <ok/>
  <transfer protocol negotiaion result//>
</iq>

Same with REL:

REL1:
<iq type='set'>
  <want to transfer/>
</iq>

REL2:
<iq type='result'>
  <ok/>
</iq>

REL3:
<iq type='set'>
  <transfer protocol negotiaion/>
</iq>

REL4:
<iq type='result'>
  <transfer protocol negotiaion result//>
</iq>

But with REL we can have many steps like REL1 and REL2, which is impossible
with Profiles.  That is advantage of REL that I see.

 RE> The other difference between Justin's protocol and Thomas' is the idea of
 RE> automatic fail over if a stream fails to send a file.

 RE> This just doesn't sit right with me.  If a transfer fails (for any
 RE> reason), then you should just have to restart it and pick a different
 RE> method.  It is easy enough for a client to implement special features to
 RE> automate it's side, but I do not think that it should be required in the
 RE> protocol.

 RE> In all other respects, the two methodologies are almost identical.  Any
 RE> thoughts from other Council folk?



More information about the Standards mailing list