[Standards] file transfer

Richard Dobson richard at dobson-i.net
Tue Aug 28 21:55:36 UTC 2007


> It's unclear exactly what you mean. You want a Jingle method as one
> option in stream initiation, like this?

Not quite, it would be more like this:

<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-single'>
           <option>
             <value>urn:xmpp:jingle:bytestreams</value>
           </option>
           <option>
             <value>http://jabber.org/protocol/bytestreams</value>
           </option>
           <option>
             <value>http://jabber.org/protocol/ibb</value>
           </option>
         </field>
       </x>
     </feature>
   </si>
</iq>

i.e. completely backwards compatible for all receiving clients, only 
clients that know about the jingle bytestream method would try to use 
it, others would fall back to traditional methods, all without needing a 
separate jingle file transfer offer mechanism with all the associated 
discovery and duplicate implementation and complexity that would arise 
from that.

> And then you do a Jingle negotiation to figure out how to proceed?

Only in that jingle would be negotiating a generic bytestream just as 
how SOCKS5 and IBB work and then passing the file to it.

> See earlier list discussion. We had rough consensus that in the long
> term client developers didn't want both SI and Jingle as negotiation
> mechanisms -- that it would be easier to have just one approach.

Maybe, but ive seen plenty of people also comment that they dont like 
the fact they are going to have to implement two different file transfer 
establishment methods in order to maintain backwards compatibility, also 
I dont seem to remember anyone suggesting this particular compromise 
back then and I wanted to see what people thought about it, so far two 
votes for yes.

Richard




More information about the Standards mailing list