[Standards-JIG] pubsub: questions and comments
gaston at jivesoftware.com
Wed Feb 22 17:38:57 UTC 2006
1) I guess that pending subscriptions should be authorized when a user
becomes publisher or owner. Is this correct? Should we make this explicit in
the JEP? The opposite would apply when making a user an OUTCAST. Any pending
subscription should be cancelled.
2) The JEP allows to retrieve the default configuration of nodes but there
is no way to edit the default node configuration values. I think that it
would be useful to let sysadmin change the default configuration to use for
new nodes. And it would help to have this functionality standardized in the
3) Some nodes may require that new subscriptions be completed by setting the
subscription options. However, there is no field in the node#conf form to
specify if subscription options are required. Should we add this field to
the form so it's standardized?
4) Collection nodes cannot have published items so asking to purge a
collection node makes no sense. Unless we want to trigger a cascade purge
down the hierarchy (but let's leave this out for now). Should we return a
specific error when an owner asks to purge a collection node? Or is
feature_not_implemented/unsupported feature=persistent-items the correct
error to return?
5) Is it possible to delete a collection node that has children nodes? If
the answer is that some services may delete the whole hierarchy while others
don't then what error should the service return when it's not allowed to
delete the node?
6) Instant rooms in MUC are usually destroyed when the last occupant leaves
the room since the room is usually not persistent. On the other hand,
instant nodes means that node IDs are generated by the pubsub service. But I
guess that these nodes are persistent so even after a server restart they
are still there. Therefore, I infer that the way to delete an instant node
is just like any other node. Is this right?
7) FROM and TO are inverted in example 84.
8) Example 102 is missing TO='pubsub.shakespeare.lit'
9) In Example 145 entity subscribes to root collection node but comment says
10) Should attribute "node" be required in
http://jabber.org/protocol/pubsub#owner? Or when it's missing it means that
root node is being configured?
11) Possible inconsistency: To subscribe to root node the node attribute
should/may not be specified but to edit subscription options the node
attribute is required. I think that if root node is represented by the lack
of the node attribute then the <options> element should have the node
attribute as optional.
12) I think that the <configure> element in
namespace=http://jabber.org/protocol/pubsub should not have a node
attribute. When creating new nodes the node attribute is being specified in
the <create> element. Should we fix the schema?
13) In section "6.1 Subscribe to a Node" we have the following text: "In the
same way, implementations MAY enable blacklisting of entities which are not
allowed to perform specific operations (such as subscribing or creating
nodes)". I think that OUTCAST affiliations fall into this category. If they
do then is it optional to support OUTCASTs? If it's not optional then
shouldn't the above text use a SHOULD/MUST instead of a MAY? And add a
comment saying that the blacklist is defined by OUTCAST affiliations.
14) What error should the service return when an OUTCAST tries to subscribe
to the node?
15) This questions is actually related to the "how to build the 1-n
relationship between affiliations and subscriptions" problem. When a user
creates a new node, the user becomes the node creator but also the node
owner. Since the <create> element does not specify any subscription JID,
both the new affiliation of type "owner" and the new subscription with
status "subscribed" are created for the full JID of the user. Having the
full JID of the user as the node owner is not very convenient for IM users
since that means that they can only administer the node using the specified
resource. IMHO, we should also include the "owner" attribute to the <create>
element so that the affiliation is created using the owner value and if none
was defined then the sender of the IQ packet is used instead. What do you
Thanks for reading all these questions. :)
More information about the Standards