22
edits
Difference between revisions of "PubSubIssues"
Jump to navigation
Jump to search
→No text on #publish_model
(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...") |
|||
| (10 intermediate revisions by 2 users 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. | ||
=== | === Temporary Subscriptions is not discoverable (Section 12.4) === | ||
http://xmpp.org/extensions/xep-0060.html#impl-tempsub describes temprary subscriptions for a pub/sub node. It is not mentioned anywhere in the XEP-0060 how to discover this feature (pubsub#tempsub). | |||
=== 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 (Section 5.3 and 5.5) === | |||
Would be good if the PubSub spec would have a reference to the service discovery error conditions if a disco request is send to a non existent 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). So it's not clear for some implementors what do in this case (which is likely because the relevant information is found in a different XEP). | |||
=== Optional redirect URI for <delete/> not discoverable (Section 8.4) === | |||
Server support for <redirect/> is optional for servers, yet clients have no way of discovering if the server supports it. Also, it doesn't state the maximum number of <redirect/> elements allowed, although it seems to suggest it's one. Proposed solution: | |||
* Add feature delete-nodes-redirect (OPTIONAL) | |||
* Modify language to state there can be only one redirect element. | |||
=== Redundant features for Item Retraction === | |||
The latest revision introduced a feature 'delete-items', while 'retract-items' was already there. Ralphm proposed to the list: | |||
<blockquote> | |||
[...] Reading the text around it, I feel it is | |||
confusing, too. I'd rather go with talking about 'retracting items' and | |||
'deleting nodes' thoughout, and not talk about 'deleting items'. | |||
</blockquote> | |||
<blockquote> | |||
I think that many (all?) clients ignore this feature for discovery | |||
altogether, so what about making 'delete-items' a thing that servers | |||
SHOULD also advertise along with 'retract-items', but have clients | |||
depend on 'retract-items' exclusively? | |||
</blockquote> | |||
=== No text on #publish_model === | |||
A few examples mention an option #publish_model, which seems useful, but there's no actual text describing behaviour of said option. | |||
=== Entity node creation authorization request (Section 8.1) === | |||
There's no way to know if an entity can create (or not) a node before actually create it. | |||
This issue bring a bad UI experience on some Pubsub clients (we display an error after the form creation submission). | |||
== XEP-0163: PEP == | == XEP-0163: PEP == | ||