[jdev] Different behaviors of ejabbered and openFire in pushing messages to the client!

[Sylvain Hellegouarch]

Thanks for this summary because I've been reading these sections of RFC 
3921 *a lot* and there are so many different combinations that I lose it 
quickly.

/me pokes psa too. A diagram of all the different interactions would go 
a long way /me thinks

- Sylvain

Mridul Muralidharan a écrit :
>
> Hi,
>
>   I think Peter is in the process of clarifying the bis spec on the 
> subscription appendix's. /me pokes psa :)
> It might be a good idea to wait for that to be complete ... currently, 
> the state of specs is a bit icky from an impl point of view (though 
> well defined).
>
> Roughly, 3921 says these :
>
> - a user can add any contact to his roster, this does not trigger a 
> presence subscription request - but a roster push(*) will occur.
>
> - a user can ask for subscription to contact : (if contact is not in 
> the user's roster (step 1 omitted), it gets automatically added) this 
> triggers a roster push(*) with change in subscription status (ask
> attribute).
>
> - if contact is online, subscribe is pushed to all available resources 
> using rules similar to roster push(*).
>
> - if contact is offline or no resource is available which satisfies 
> rule for roster push(*), this is stored for later delivery.
>
> - if contact rejects subscription (unsubscribed), this triggers a 
> roster update in user's roster appropriately (must not result in 
> removal of entry - I see that some servers remove the contact's jid 
> from user roster) and a corresponding roster push(*).
>
> - 3921 says that the unsubscribed must be delivered to the user's 
> resources(*).
>
> (*) The roster push above will happen only to all resources which have 
> requested (or modified) roster in some way (including asking for 
> subscription).
>
> Similar steps above when contact's approves subscription.
>
> The state table related to inbound unsubscribe, unsubscribed and 
> subscribed could be changed for 3921 bis spec (it has already been 
> changed for subscribed). If I am not wrong, the last step above would 
> not happen - that is, unsubscribe(d) will not be routed to the user.
>
> Here, I assumed that there is no subscription between user & contact, 
> if that is present, it just adds more to the flow - refer to section 9 
> in 3921 [1]
>
> Hope this clarifies. The steps above are the same irrespective of 
> whether it is a local contact, s2s contact, clustered configuration or 
> other combinations.
>
> Regards,
> Mridul
>
> [1] http://www.xmpp.org/rfcs/rfc3921.html#substates
>
> Tran Thai Son wrote:
>> Hi all,
>>
>> I am writing a client and I've experienced different behaviors from 
>> different servers in handling client's actions such as add / accept / 
>> deny subscription requests. What surprised me is that it seems there 
>> is no standard behaviors ( e.g. processes of treating actions, order 
>> of notification messages pushing to the clients...) for the server.
>>
>> E.g.:
>> - ejabbered 1.1.3 always adds the incoming contact to the user's 
>> roster (with the subscription status = 0, means no relationship) 
>> before pushing the subscription (add-friend) request to the user. So 
>> the client gets two messages: one to notify that there is an item 
>> added, the next to notify that there is a subscription request.
>> - meanwhile, openFire 3.3.1 does not add the contact before, so you 
>> get only the later message. One (probably) bug I found: even when the 
>> client sent a message denying the subscription request, the server 
>> still adds the contact to the user's roster (with subscription= 0)
>>
>> Furthermore, with the same actions from the clients, the number  and 
>> order of messages that the servers send significantly different.
>> E.g.
>> - ejabbered 1.1.3 tends to not to send any message to the contact 
>> with subscription = 0. Example: If user B denied a subscription 
>> request from user B (means no relationship at the moment), B will not 
>> receive the next unsubscription request from A, but with openFire 
>> 3.3.1, it will.
>> - Furthermore, I found the order of messages that openFire pushes to 
>> the clients rather annoying. For example, if user A removes user B 
>> from its roster (and therefore B will also remove A - my 
>> implementation), A will receive "unsubscribed" and "unsubscribe" 
>> (respectively) from B before received the notification that its 
>> removal was done. So you cannot trust that: when you remove a contact 
>> from your roster, you won't receive unexpected message from that 
>> contact; You also see that contact still in your roster for a while 
>> (with subscription = 0).
>>
>> Does any body experience similar problems ?
>>
>> Son.
>>
>>
>>