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

[Pidgin]

#11819: XMPP presence and chatstatus with bare JIDs
--------------------------------------------------+-------------------------
 Reporter:  dimakcgs                              |        Owner:  deryni
     Type:  defect                                |       Status:  closed
Milestone:  2.7.1                                 |    Component:  XMPP  
  Version:  2.6.6                                 |   Resolution:  fixed 
 Keywords:  presence aggregation JID CommuniGate  |  
--------------------------------------------------+-------------------------
Changes (by darkrain42):

  * keywords:  XMPP presence aggregation JID CommuniGate => presence
               aggregation JID CommuniGate


Comment:

 I shouldn't really argue (but feel like I should anyway, since it lets off
 steam).  Fair warning. :P

 For clarity, the core issue is that coalescing presence information to the
 bare JID ''while sending messages'' from full JIDs is stupid and counter-
 productive.  There are a number of XEPs (and frankly, I bet rfc3921(bis?)
 does, but I'm lazy) that make the assumption that two parties
 communicating SHOULD (and often DO) exchange presence (this is one of the
 great things about XEP-0115 Entity Capabilities), as well that if we have
 a subscription to a buddy (and we get a presence either from a bare JID or
 from resources, we've gotten ''all'' the presences from ''all'' of those
 resources (there's a MUST in rfc3921 about broadcasting initial presence
 with a 'from' of the full JID).

 Coalescing presence also breaks the ability to enable/disable features
 based on what the remote client will support (because we don't know which
 client we're talking to!), not to mention the ability of a power user to
 specifically address messages to a particular resource that he sees ("Oh,
 I don't want to bother Joe with this at the office, ''selects Home
 resource''".)  It's made impractical if resource-presence aren't
 advertised.  (Ignore the fact Pidgin can't easily direct messages to
 specific resources)

 Replying to [comment:5 dimakcgs]:
 > Here's what our senior developer suggests:

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

 I disagree that they can be totally separated (and see above for the ways
 in which there ''are'' links between presence and IMing -- various XEPs
 also talk about "discovering support" based off Entity
 Capabilities/Disco#info)

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

 The issue is(was) actually that the XMPP prpl tracks whether or not an
 entity supports chat states on a per-''resource'' basis (it's stored in
 the !JabberBuddyResource struct), and those structs are created/destroyed
 when libpurple receives presence from a JID (that's the cleanest way to
 not need to have some narsty "garbage collection" process for those
 structs).

 The issue becomes self-evident at this point :)

 I ended up fixing it in a way that doesn't leave a bitter taste in my
 mouth because it has plausible use cases other than this (one-way presence
 subscriptions and/or an "invisible" buddy)

 > 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 is reasonable (and I'll make the change), though isn't applicable to
 the current situation AFAICT.

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

 It's not that there hasn't been any presence (if that were the case, I
 could just say "libpurple doesn't send typing notifications to entities
 not on the buddy list" and that would be that), it's that the server is
 explicitly crippling XMPP in a way that I don't see any use in, plausibly
 violates a few MUSTs in the RFCs, and, as you've discovered, causes issues
 in other clients which make what I believe to be reasonable assumptions
 about presence-from-bare-JID.

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