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='[EMAIL PROTECTED]/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
