/me waves at Peter!
Peter Saint-Andre a écrit :
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.
