When offering a file transfer, if the peer has the jingle-share cap and we have a Google relay token, Gabble prefers to use jingle-share (using a confusing bit of logic in gabble_file_transfer_channel_offer_file() which I am about to clarify).
Unfortunately, the offer includes almost none of the Channel.Type.FileTransfer or Channel.I.FileTransfer.Metadata properties:
* iq xmlns='jabber:client' type='set' to='yyy' id='77863471642'
* session xmlns='http://www.google.com/session' initiator='xxx' id='568990973' type='initiate'
* description xmlns='http://www.google.com/session/share'
* file size='5343'
* url name='source-path'
* url name='preview-path'
* transport xmlns='http://www.google.com/transport/p2p'
This broke my attempt to use Metadata.ServiceName to make LibreOffice a BypassApprovers-flavoured handler for file transfers directed to it. It also broke my follow-up attempt to (ab)use Description for the same purpose.
Whether or not adding extra data (like ContentType, etc.) to the <file/> element would break Google clients, it seems reasonable (at the very least) to include everything if we know the peer supports our Metadata extension.
(In reply to comment #0)
> (using a confusing bit
> of logic in gabble_file_transfer_channel_offer_file() which I am about to
Confusing enough that I misunderstood it while trying to simplify it. Hooray for tests. I'll just leave it.
So, more specifically. offer_bytestream() in ft-channel.c adds desc="" attributes etc. and also calls add_metadata_forms(): http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/ft-channel.c#n1195
But when using the GTalk file transfer protocol, offer_gtalk_file_transfer() is called instead <http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/ft-channel.c#n1339> which ultimately calls produce_description() <http://cgit.freedesktop.org/telepathy/telepathy-gabble/tree/src/jingle-share.c#n443> which as you can see does not add a description or anything.