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.

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.

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.

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?

Yes, it is still valid.