PubSubIssues

This page lists known issues with the Publish-Subscribe specifications (XEP-0060, XEP-0163, XEP-248).

XEP-0060: PubSub

Note: these issues are keyed to the section numbers in version 1.13 of XEP-0060.

Affiliation Change Notifications (Section 8.9.4)

• Affiliation change notifications are qualified by the 'http://jabber.org/protocol/pubsub' namespace, but should be qualified by the 'http://jabber.org/protocol/pubsub#event' namespace.
• The affiliation element, qualified by the 'http://jabber.org/protocol/pubsub' namespace, does not have a jid attribute
• The section mentions that a body element can be provided and used to specify natural-language text regarding the affiliation change.

Details and Suggested Changes

Currently, the notification for affiliation changes uses the affiliation element found in the pubsub namespace. This conflicts with all other notifications, that refer to matching elements defined in the pubsub#event namespace. Affiliations are genetically similar to subscriptions and should mimic how subscription notifications are handled. Resolving this requires the following changes:

• Update the schema, in section 17.4, to include the affiliation element as an option under the event element.
• Update the schema, in section 17.4, to include a definition for the affiliation element.
  • The new affiliation element should include a node, jid and affiliation attribute.
• Update Example 208 to more closely match Example 194.
  • Replace pubsub element with the event element.
  • Remove the affiliations element
  • Update the affiliation element to include the node attribute that was in the affiliations element
• Investigate whether the body element can be used to provide change related text to any notification messages. If it can, each notification area should include this information or the information should be place in a general location.
• Section 7.1.2.3 says: "If configured to do so, the service can include the publisher of the item when it generates event notifications." but there is no way to configure this bevahiour described. Probably need to add appropriate discovery feature + configuration form item.

Expected response to disco info and disco items request to a non existing node is not specified (Section 5.3 and 5.5)

It is not specified what the PubSub service should return if the client performs a disco info or disco items request on a non-existent PubSub node. I've reports from users that some implementations return a non-error result, which e.g. results in Smack returning a NotAPubSubNodeException instead of a XMPPErrorException (which is what most would expect).

XEP-0163: PEP

No known issues.

XEP-0248: Collections

Needs a general overhaul.