jingle-share protocol silently drops most file transfer properties & metadata

Submitted by Will Thompson @wjt

Assigned to Telepathy bugs list

Link to original bug (#47936)

Description

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'
      • manifest
        • file size='5343'
          • name "write-manager-file.py"
      • protocol
        • http
          • url name='source-path' "/temporary/fefff52b-3e03-40a1-8370-6bed61a4935b/"
          • url name='preview-path' "/temporary/68a248ad-1173-4abc-80ae-66e0614aadc1/"
    • 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 element would break Google clients, it seems reasonable (at the very least) to include everything if we know the peer supports our Metadata extension.

Version: git master