We're updating the issue view to help you get more done. 

Subscriptions to pubsub node should be based on the JID as supplied, not the bare JID

Description

Subscription owner should be the jid as supplied, not the bare jid. The spec says that any jid should be able to be used. Currently all subscriptions are stored using the bare jid as the owner.

Environment

None

Acceptance Test - Entry

None

Activity

Show:
Robin Collier
March 11, 2013, 6:10 PM

Yes, it is still valid.

Tom Evans
April 12, 2013, 9:01 PM

It appears that the current implementation presumes that a subscription must exist for any owner and/or publisher, and as a result will try to create a subscription if one does not already exist for the corresponding bare JID. This has the unfortunate side effect of creating implicit subscriptions (using the bare JID) for all owners and publishers. We believe this is the root cause of the unnecessary (and undesirable) additional notification deliveries.

I have checked the current specification (XEP-0060) and see no mention of a "subscribed" post-condition for either node creation or node affiliation change(s). I am proposing that we remove these extraneous subscriptions and only deliver item notifications for active subscriptions that have been explicitly created.

Thoughts/comments?

Tom Evans
April 13, 2013, 1:04 AM
Edited

OK - I believe we have a fix for this problem now. In addition to the changes described above, I have added a check to prevent delivery of pubsub notification event messages if the corresponding subscriber JID is unavailable. This is necessary because Openfire will re-route pubsub messages using the bare JID if delivery via the full subscriber JID fails.

I have committed the proposed changes, but I am still attempting to re-run the Smack-based pubsub regression tests against the new build. Unfortunately I am having a little trouble with this validation step. I will keep the ticket open a while longer pending additional testing.

Robin Collier
April 14, 2013, 2:26 PM

You should check against the 1.8 version of the spec regarding this issue, as that is the current implementation of Openfire. Most likely it is still the same, but you should confirm that so the implementation isn't a hybrid of multiple versions.

Determining whether to send to an offline subscriber is a configuration option of the node. So only the property pubsub#presence_based_delivery should determine whether to check or not.

Tom Evans
April 16, 2013, 9:03 PM

OK - I reviewed the spec (including the older 1.8 revision) and came up with the following, based on the implementation guidelines:

  1. We SHOULD NOT deliver event notifications to the user's bare JID if the subscription is designated for a full JID.

  2. We SHOULD NOT persist event notification messages via the offline message store.

In effect, this means we should not attempt to deliver event notification messages for subscriber JIDs that are unavailable. I have added comments inline to clarify this interpretation.

As an aside, there is additional guidance in the specs about various ways to detect and cancel defunct or obsolete subscriptions, including a delivery "bounce counter", but this capability does not currently exist in the Openfire implementation. I will create a separate ticket to track this as a enhancement request for the future.

Fixed

Assignee

Tom Evans

Reporter

Robin Collier

Labels

None

Expected Effort

None

Ignite Forum URL

None

Components

Fix versions

Priority

Major
Configure