[Pidgin] #11819: XMPP presence and chatstatus with bare JIDs

Tue May 11 03:02:23 EDT 2010

#11819: XMPP presence and chatstatus with bare JIDs
-------------------------------------------------------+--------------------
 Reporter:  dimakcgs                                   |        Owner:  deryni
     Type:  defect                                     |       Status:  new   
Milestone:                                             |    Component:  XMPP  
  Version:  2.6.6                                      |   Resolution:        
 Keywords:  XMPP presence aggregation JID CommuniGate  |  
-------------------------------------------------------+--------------------

Comment(by dimakcgs):

 Here's what our senior developer suggests:

 First of all, presence and IM are different protocols within XMPP, though
 many
 clients (and sometimes server) do provide some sort of "integration"
 between
 the two.

 But in this case, we really do not see why there should be a link between
 the
 presence and IMing. We are talking about the IM session behaviour. The
 <message>
 stanza are exchanged between your client and "something" on the other end.

 That something may or may not have a resource. In our case, it does have a
 resource
 name in it. When your client starts the session itself, it does not know
 anything about the resource on the other end, so it sends all <message >
 stanza to bare JID.

 It ASSUMES that the other end understands the "chatstates" protocol, so it
 sends
 the <composing />, <paused />, etc. messages - all the bare JID. So far so
 good.

 Now, it gets a reply from the "other end". And, most likely, it gets the
 resource name in that reply. Here you client can make a smart decision: if
 the other end does not support the "chatstates"  namespace, it can stop
 sending its own state - as it's simply waste of the traffic.

 AND - if we read the libpurple source code right, it does EXACTLY THAT. If
 an incoming <message /> stanza contains any <xxxxx
 xmlns="http://jabber/protocol/chatstates"> element, then you assume that
 the "other" end supports this protocol, otherwise - that it does not
 support it.

 BUT: somwhere along these lines (we guess outside the libpruple code) your
 client also tries to check the information it go from the same resource in
 the latest <presence /> stanze.
 And it does not find it (as all <presence > stanzas come agrregated by the
 other end).
 AND here - we think - is the problem: in this situation your client does
 not IGNORE the <presence /> data when it's absent, but treats it as "the
 other end does not support anything".
 This, it deletes the just-collected information about the
 xmlns="http://jabber/protocol/chatstates" support.

 We think it's not the best method to handle the situation, and if you
 change it so that lack of <presence /> from the same resource does not
 OVERRIDE the already collected information about this resource (collected
 from the incomding <message /> stanzas), it would solve many problems.

 Finally - we do not think that the simple algorithm we saw in libpurple
 processing of the <message /> stanza is the best one. If you do see a
 xmlns="http://jabber/protocol/chatstates" element, you can safely assume
 that the other end supports this protocol. But if you do not see it, it's
 quite risky to assume that it does not: it can be  service <message />
 stanza delliverying  any other info.
 Our suggestion would be to have the flag for that option set to "unknown",
 "supported", "unsupported" (you already have it there), and set the flag
 to "unknown" initially. Then, you always set to to "supported" when you
 see a xmlns="http://jabber/protocol/chatstates" element, but you set it
 to "unsupported" ONLY if you get a <message /> stanza without
 xmlns="http://jabber/protocol/chatstates" element AND the flag is
 currently "unknown" AND the <message /> stanza contains  a <body /> or an
 <html /> element.

 This way if you see xmlns="http://jabber/protocol/chatstates" once from
 the client, you will not reset it if it sends some service <message />
 later. And at the beginning, if the client has not sent any
 xmlns="http://jabber/protocol/chatstates" with or before a "real" <message
 /> (i.e. one delivering some text), then you may assume that this client
 does not support the xmlns="http://jabber/protocol/chatstates".

 But - it's just a suggestion, we do not have any problem with libpurple
 using the curreny simple yes/no algorithm, it's just an iprovement
 suggestion.

 But the problem with linking of IM and presence data when the presence
 from this particular resource has never been received - this is a serious
 problem for our customers now.

 Thank you for your cooperation.

-- 
Ticket URL: <http://developer.pidgin.im/ticket/11819#comment:5>
Pidgin <http://pidgin.im>
Pidgin