Thanks for the information, too. Now all we can do is to make the client as fault-tolerant as possible :)
On 19/06/07, Sylvain Hellegouarch <[EMAIL PROTECTED]> 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. >> >> >>
