[Standards-JIG] Re: pubsub: questions and comments

Peter Saint-Andre stpeter at jabber.org
Tue Feb 28 20:29:52 UTC 2006

Hash: SHA1

Gaston Dombiak wrote:
> "Peter Saint-Andre" <stpeter at jabber.org> wrote in message 

>>> 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?
> Hmm, I haven't realized that this option could be related to node types + 
> access model. Anyway, I think that making mandatory to configure 
> subscriptions may depend on things out of the scope of pubsub (i.e. other 
> business rules) so the service can propose a default value based on an 
> optional smart logic and let the owner override the default value. I usually 
> like not-locking solutions and let users configure the application as they 
> see fit.

Yes, I think that whether a node requires a subscriber to configure
subscription options may depend on things outside pubsub protocol
itself, so I don't know if it makes sense to specify the rules for this
in the JEP. In any case, I also think that it would be best to leave
this up to the service, and not force the node owner to toggle whether
subscription options need to be configured. I still don't see good use
cases for why the node owner would need to do that. I'm not opposed to
it, just trying to figure out whether it's really needed.

>>> 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.
> Agreed. More about this in 
> http://mail.jabber.org/pipermail/standards-jig/2006-February/010066.html. 
> Let me know if you want to discuss this by IM.

OK, I'll start a separate thread about that, I think.

>>> 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).
> Ok, so entities may have many subscriptions of type "items" but only one of 
> type "nodes" with a node collection. Is that correct?

Yes, I think that's right.


- --
Peter Saint-Andre
Jabber Software Foundation

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

-------------- 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/20060228/604ef2c9/attachment.bin>

More information about the Standards mailing list