http://telepathy.freedesktop.org/spec/Connection_Interface_Contact_Info.html#Property:SupportedFields Here is the value of this property on my Facebook account: [(u'fn', [], 1L, 1L), (u'bday', [], 1L, 4294967295L), (u'mailer', [], 1L, 4294967295L), (u'tz', [], 1L, 4294967295L), (u'title', [], 1L, 4294967295L), (u'role', [], 1L, 4294967295L), (u'note', [], 1L, 4294967295L), (u'prodid', [], 1L, 4294967295L), (u'rev', [], 1L, 4294967295L), (u'sort-string', [], 1L, 4294967295L), (u'uid', [], 1L, 4294967295L), (u'url', [], 1L, 4294967295L), (u'nickname', [], 3L, 4294967295L), (u'x-jabber', [], 1L, 4294967295L), (u'x-desc', [], 1L, 4294967295L), (u'n', [], 1L, 1L), (u'adr', [u'type=home', u'type=work', u'type=postal', u'type=parcel', u'type=dom', u'type=intl', u'type=pref'], 0L, 4294967295L), (u'geo', [], 1L, 1L), (u'tel', [u'type=home', u'type=work', u'type=voice', u'type=fax', u'type=pager', u'type=msg', u'type=cell', u'type=video', u'type=bbs', u'type=modem', u'type=isdn', u'type=pcs', u'type=pref'], 0L, 4294967295L), (u'email', [u'type=home', u'type=work', u'type=internet', u'type=pref', u'type=x400'], 0L, 4294967295L), (u'label', [u'type=home', u'type=work', u'type=postal', u'type=parcel', u'type=dom', u'type=intl', u'type=pref'], 0L, 4294967295L), (u'org', [], 1L, 4294967295L)] I'm pretty sure Facebook doesn't allow us to set all this. Actually, calling SetContactInfo() raises this error: error_name=org.freedesktop.Telepathy.Error.NotAvailable reply_serial=310 string "the feature requested is not implemented by the recipient or server and therefore cannot be processed" Also, having a field sharing a billion of 'type=' looks weird as well. Aren't we supposed to have max one type? The latter problem doesn't seem specific to Facebook, see http://willthompson.co.uk/misc/xmpp-personal-info.png
(In reply to comment #0) > Here is the value of this property on my Facebook account: ... > I'm pretty sure Facebook doesn't allow us to set all this. No, it doesn't allow us to set *any* of it, AIUI - but I don't see how we can do better without either the Facebook server setting an anticapability, or us hard-coding some way to detect the Facebook server and disallow it. (The latter approach has the risk that Facebook people later make it work and Gabble still falsely claims that it doesn't.) > Also, having a field sharing a billion of 'type=' looks weird as well. Aren't > we supposed to have max one type? No, in vCard it's entirely valid to say "111111 is my work mobile number for voice calls, and in general I'd prefer you to use it; 222222 is my home number, use it to send me faxes, or dial-in to the BBS on my modem because I'm obsessed with obsolete technology". That looks something like this: TEL;TYPE=WORK,CELL,VOICE,PREF:111111 TEL;TYPE=HOME,FAX,MODEM,BBS:222222 XMPP's vcard-temp is a fairly straightforward mapping of vCard into XML, so it inherits all this. Telepathy has an equally straightforward mapping of vCard into D-Bus, where we'd use: [("tel", ["type=work", "type=cell", "type=voice", "type=pref"], ["111111"]), ("tel", ["type=home", "type=fax", "type=modem", "type=bbs"], ["222222"])] Admittedly, that example is clearly silly, but if you dropped the MODEM and BBS bits it'd be entirely sane. It's certainly reasonable to want to be able to distinguish between a home fixed line, personal ("home") mobile phone, work fixed line (i.e. desk) and work-issued mobile phone, each of which has two types.
(In reply to comment #1) > (In reply to comment #0) > > Here is the value of this property on my Facebook account: > ... > > I'm pretty sure Facebook doesn't allow us to set all this. > > No, it doesn't allow us to set *any* of it, AIUI - but I don't see how we can > do better without either the Facebook server setting an anticapability, or us > hard-coding some way to detect the Facebook server and disallow it. > > (The latter approach has the risk that Facebook people later make it work and > Gabble still falsely claims that it doesn't.) I agree, the former is much better. Does XMPP provide protocol to say "no vCard for me thanks"? Now that we have a contact in the Facebook XMPP team, it would be good to make a list of all these things they don't support and ask them to properly advertise it. I suspect some XMPP work may be needed but that's worth it I think.
(In reply to comment #2) > Now that we have a contact in the Facebook XMPP team, it would be good to make > a list of all these things they don't support and ask them to properly > advertise it. That would be superb. I think the anticapabilities we'd want are something like this: * cannot edit the roster * cannot edit my own vCard * restricted <message> (?) + documentation of what the restrictions are, for when we later support XHTML-IM or whatever (plain-text only, I think?) * restricted <iq> + documentation of what the restrictions are * any other departures from XMPP Core (RFC 6120), XMPP IM & Presence (RFC 6121)
(In reply to comment #2) > Now that we have a contact in the Facebook XMPP team, it would be good to > make a list of all these things they don't support and ask them to properly > advertise it. Did this ever happen?
(In reply to comment #4) > (In reply to comment #2) > > Now that we have a contact in the Facebook XMPP team, it would be good to > > make a list of all these things they don't support and ask them to properly > > advertise it. > > Did this ever happen? Don't think so, but we can now use the "Facebook XMPP Developer Relations" group to do so : https://www.facebook.com/groups/315869928431057/?fref=ts
Afaik, facebook no longer supports XMPP, so I'm closing this report.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.