[Bug 47936] New: jingle-share protocol silently drops most file transfer properties & metadata

[bugzilla-daemon at freedesktop.org]

https://bugs.freedesktop.org/show_bug.cgi?id=47936

             Bug #: 47936
           Summary: jingle-share protocol silently drops most file
                    transfer properties & metadata
    Classification: Unclassified
           Product: Telepathy
           Version: git master
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: medium
         Component: gabble
        AssignedTo: telepathy-bugs at lists.freedesktop.org
        ReportedBy: will.thompson at collabora.co.uk
         QAContact: telepathy-bugs at lists.freedesktop.org


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 <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.

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA Contact for the bug.
You are the assignee for the bug.