Opened 11 years ago

Closed 11 years ago

Last modified 11 years ago

#4322 closed defect (wontfix)

[XMPP] Invisible mode violating standard

Reported by: js Owned by: nwalp
Milestone: Component: XMPP
Version: 2.3.1 Keywords:
Cc: js-pidgin@…

Description

Gajim sends a presence of type invisible which violates the XMPP Core Standard. See here for the correct way to handle this: http://www.xmpp.org/extensions/xep-0126.html

Change History (12)

comment:1 Changed 11 years ago by js

s/Gajim/Pidgin/ Sry, using and reporting bugs for too much clients at once :).

comment:2 Changed 11 years ago by seanegan

  • pending changed from 0 to 1

No it doesn't. There's some code that will send directed presence of type invisible which is enabled only when you're using Jabber 0.9, but if you're talking to an XMPP server, Pidgin will never do this. Why do you think it does?

comment:3 Changed 11 years ago by js

  • pending changed from 1 to 0

Sending a presence of type invisible *IS* a violation of both, the XMPP Core and the XMPP Messaging standard. It should use privacy lists instead. You should have a look at XEP 0126 which clearly states the standard violation at the beginning: “Several popular instant messaging services implement a feature known as invisibility: the ability to remain online yet appear offline to some or all of one's contacts. A number of Jabber servers and clients have also implemented such a feature, using special values of the <presence/> element's 'type' attribute (e.g., <presence type='invisible'/>). Unfortunately, such implementations are not compliant with XMPP Core [1] and XMPP IM [2], which specify that only the 'type' attribute values defined in the XML schema for the 'jabber:client' and 'jabber:server' namespaces are allowed in XMPP (and those values do not include "invisible"). However, RFC 3921 also defines a privacy lists protocol (i.e., the 'jabber:iq:privacy' namespace) that can be used to implement invisibility in an XMPP-compliant manner. This specification documents how to do just that.” So you should instead implement XEP 0126 which does not violate any standard.

comment:4 Changed 11 years ago by js

Oh, btw: If you want a quick fix, you can check if a discovery on the server returns this: <feature var='presence-invisible'/> If it does return this, you can use the old behaviour. About the thing with it does it only for jabber 0.9: Sorry, you're right. It doesn't even offer it for XMPP. But maybe you should check for the feature, so that you can use it on XMPP servers that also implement it?

comment:5 Changed 11 years ago by seanegan

  • pending changed from 0 to 1

It's probably a bad idea to support illegal protocol extensions, as client support would promote non-compliant servers.

comment:6 Changed 11 years ago by js

  • pending changed from 1 to 0

This is exactly why I proposed to remove the current way of doing invisible and use the privacy list based one instead as the invisibility command XEP isn't finished yet.

comment:7 Changed 11 years ago by seanegan

  • pending changed from 0 to 1

But we don't actually offer invisibility for XMPP, so there isn't anything to remove. I think this can be closed?

comment:8 Changed 11 years ago by js

  • pending changed from 1 to 0

In pidgin-2.3.1/libpurple/protocols/jabber/buddy.c: static void jabber_buddy_set_invisibility(JabberStream? *js, const char *who, gboolean invisible)
There is:

        if(invisible) {
                xmlnode_set_attrib(presence, "type", "invisible");
                jb->invisible |= JABBER_INVIS_BUDDY;
        } else {
                jb->invisible &= ~JABBER_INVIS_BUDDY;
        }

That looks to me like it sends a presence of type invisible. Instead, privacy lists should be used here.

comment:9 Changed 11 years ago by seanegan

  • Resolution set to wontfix
  • Status changed from new to closed

I don't think anyone would care if we got rid of it entirely, but my point is that we don't use that code at all for XMPP. We do it for Jabber servers which we have backward compatibility for.

We're not likely to implement privacy lists, as they've been deemed too complex and removed from the RFCs because of it. If we wanted to support Invisible (which I really don't), we'd more likely support XEP 186.

But as it is, I don't see how we're non-compliant and why I should change anything.

comment:10 Changed 11 years ago by js

The point is that we need Privacy Lists anyway for Tools -> Privacy. Jabber is currently the only protocol where this does exactly nothing. And when we've already implemented it, we can also use it for invisibility.

comment:11 Changed 11 years ago by seanegan

In that case, this is duplicate of #1583, but I suspect that won't happen as privacy lists have been deprecated, as I understand.

comment:12 Changed 11 years ago by js

No, Privacy Lists are NOT depreacted. There's XEP 0191, but this is only an addition, not a successor of XEP 0016. It's just like with PEP: PEP's there to make it easier, but not to replace PubSub?. Same for XEP 0191: It's there to make it easier, not to replace XEP 0016. Anyway, XEP 0191 is NOT enough for the Tools -> Privacy dialog as it only allows blocking single contacts. We *need* XEP 0016 for that and Privacy Lists are definitely *not* deprecated.

Note: See TracTickets for help on using tickets.
All information, including names and email addresses, entered onto this website or sent to mailing lists affiliated with this website will be public. Do not post confidential information, especially passwords!