[Standards-JIG] pubsub: questions and comments

Gaston Dombiak 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 
JEP.

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 
"blogs" collection.

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 
think?

Thanks for reading all these questions. :)

Regards,

  -- Gato







More information about the Standards mailing list