Richard Dobson wrote: >> 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.
Oh, I see. Yeah, that would probably work in a nicely backwards-compatible way. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
