165
edits
Difference between revisions of "PubSubIssues"
Jump to navigation
Jump to search
→XEP-0060: PubSub
(Created page with "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...") |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 1: | Line 1: | ||
This page lists known issues with the Publish-Subscribe specifications (XEP-0060, XEP-0163, XEP-248). | This page lists known issues with the Publish-Subscribe specifications ([http://xmpp.org/extensions/xep-0060.html XEP-0060], [http://xmpp.org/extensions/xep-0163.html XEP-0163], [http://xmpp.org/extensions/xep-0248.html XEP-248]). | ||
== XEP-0060: PubSub == | == XEP-0060: PubSub == | ||
| Line 5: | Line 5: | ||
Note: these issues are keyed to the section numbers in version 1.13 of XEP-0060. | Note: these issues are keyed to the section numbers in version 1.13 of XEP-0060. | ||
=== Affiliation Change Notifications === | === 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 == | == XEP-0163: PEP == | ||