You are here

Home › Content

Subscription Process

Mon, 19/11/2007 - 13:58 — matben

The subscription process is notoriously problematic in XMPP. While doing extended support for multiple simultaneous subscriptions, I just noted that if I deny a subscription by sending "unsubscribed", that used to be all that was needed.

But now I see that there is still a roster item in my roster with subscription="none". It looks like ejabberd just adds it there and does not remove it when I deny the subscription. Going back to the XMPP "bible" to find out what actually shall happen, I see that it is allowed by the server to do so for tracking purposes, but it should be cleaned up after a contact denies. I cite sect. 8.2.1: "Note: If the contact's server previously added the user to the contact's roster for tracking purposes, it MUST remove the relevant item at this time."

From a users perspective I find it doubtful that I get a roster item while I'm in the middle of processing a subscription request. I think a server shall handle this tracking internally and not push items to a user before it has had any chance to reject or deny.

Story type: 
Matben's blog
Development

Comments

Tue, 20/11/2007 - 09:13 — matben

I can add the following to what I've said above. When I continued to read the RFC I found in section 9.1 (Defined States):

3: "None + Pending In" = contact and user are not subscribed to each other, and contact has sent user a subscription request but user has not replied yet (note: contact's server SHOULD NOT push or deliver roster items in this state, but instead SHOULD wait until contact has approved subscription request from user)

That's what I said above, and it looks like an inconsistency of the RFC and a bug in ejabberd.

Tue, 04/12/2007 - 21:30 — Badlop

The bug is tracked here: Roster item shoud not be added if user does not authorize contact. It was fixed some time ago, but ejabberd 1.1.4 didn't include the fix yet.

I verified it's fixed in ejabberd SVN using Coccinella 0.96.2 and Psi 0.11.

Regarding the inconsistency in RFC3921: the revised version will be more restrictive since the server is not allowed to add the roster item until the user accepts the subscription request. That will solve the inconsistency, but require some work in ejabberd to adapt to it, right? :)

Wed, 12/12/2007 - 08:29 — matben

Excellent!
I always tend to lag behind all others ;-)
I hope the Gtalk server also will follow the standards, but the big ones are never in the same race as ordinary people.

Except where otherwise noted, this work is licensed under a Creative Commons License.