[Standards-JIG] pubsub: questions and comments

Peter Saint-Andre stpeter at jabber.org
Tue Feb 28 02:55:06 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Gaston, thanks for the questions, and sorry for the delay in replying.

Gaston Dombiak wrote:

> 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.

Good point. That's implicit but it's never good to rely on implicit
understanding -- at least not in protocol specs. ;-)

> 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.

Hmm, SysAdmin use cases, eh? We avoided those in JEP-0045 (perhaps that
was not a good idea), which is probably why we don't have any in
JEP-0060 either. Could we perhaps add this in version 1.9?

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

I think a service should be smart about when to require configuration of
subscription options (e.g., depending on the node type and access model
and such), thus shielding the node owner from having to decide. I'm not
100% sure we need a node configuration option for this. What are the use
cases for when a node owner would need to toggle this?

> 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). 

Yes, let's. :-)

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

I think this is more natural:

<error type='cancel'>
  <feature-not-implemented xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  <unsupported xmlns='http://jabber.org/protocol/pubsub#errors'
               feature='purge-nodes'/>
</error>

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

In general I think if the collection node is deleted, the associated
nodes become orphans (associated only with the root node). It seems
dangerous to assume that the relationship of a collection node to its
associated nodes is hierarchical. I suppose it is possible for some
pubsub services to offer node hierarchies via collection nodes, but that
is not the only possible relationship.

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

Yes, that is correct. The analogies between MUC and pubsub do not always
hold up.

> 7) FROM and TO are inverted in example 84.

Fixed.

> 8) Example 102 is missing TO='pubsub.shakespeare.lit'

Fixed.

> 9) In Example 145 entity subscribes to root collection node but comment says 
> "blogs" collection.

Corrected to include the node in the subscribe request.

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

I think the latter.

> 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.

Fixed.

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

Yes, done.

> 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.

Section 4.1 says: "Support for the Subscriber and Owner affiliations is
REQUIRED. Support for all other affiliations is RECOMMENDED."

While the outcast affiliation is one way that a node owner can blacklist
an entity, there may be other ways that a node owner or (more likely) a
service admin can blacklist entities (e.g., a service-wide blacklist
that is accessed in some other way).

> 14) What error should the service return when an OUTCAST tries to subscribe 
> to the node?

<forbidden/>

I've added this error case to section 6.1.

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

Hrm. Yes, we probably need to make the owner JID explicit, because
truncation of a (seeming) full JID to a bare JID can be unreliable.

And the bonus question!

> 16) In section "9.2 Subscribing to a Collection Node" we found the
> following text: "A service MAY allow an entity to subscribe to a
> collection node twice, once with a subscription of type "nodes" (to
> receive notification of any new nodes added to the collection or the
> entire tree) and once with a subscription of type "items"". If the
> pubsub service supports many subscriptions to leaf nodes then
> shouldn't we allow users to subscribe to collection nodes many times
> when subscription is of type "items"?

Sure. The point here is that the service should allow both "nodes" and
"items" subscription types -- it is not meant to limit the number of
"items" subscriptions (as described elsewhere in the JEP).

Peter

- --
Peter Saint-Andre
Jabber Software Foundation
http://www.jabber.org/people/stpeter.shtml

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEA7uKNF1RSzyt3NURAsPXAKDTEZlCI7UT2IE1e7t6Q3ds9Ri+KwCghwej
BD4poGwXEaN2fgf6RvMS9nU=
=LN0t
-----END PGP SIGNATURE-----
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3641 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20060227/52dbdb46/attachment.bin>


More information about the Standards mailing list