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

[Peter Saint-Andre]

All will be revealed in rfc3921bis. :)

But I need to finish my edits to rfc3920bis first...

Soon.

/psa

Sylvain Hellegouarch wrote:
> 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.
>>>
>>>
>>>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 7358 bytes
Desc: S/MIME Cryptographic Signature
URL: <https://www.jabber.org/jdev/attachments/20070619/40730f64/attachment-0002.bin>