[Standards-JIG] Re: pubsub: affiliations and subscriptions

Gaston Dombiak gaston at jivesoftware.com
Tue Feb 21 21:27:55 UTC 2006

Hey guys,

I think that there is a previous problem that we need to figure out before 
discussing how affiliations and subscriptions should be exposed. IMHO, the 
main issue here is to figure out how should the 1-n relationship between 
affiliations and subscriptions be built. In other words, how does the pubsub 
service know that a new subscription request belongs to an existing 
affiliate and not to a new or other existing affiliate.

Let me give you an example to clarify what I'm trying to say here. Following 
with the example provided by StPeter I will change the sequence in which the 
subscriptions were made.

1. A subscription to JID = juliet at capulet.com/balcony is sent to the pubsub 
service (with SubID = sub2)
2. A subscription to JID = juliet at capulet.com/chamber  is sent to the pubsub 
service (with SubID = sub3)
3. A subscription to JID = juliet at capulet.com  is sent to the pubsub service 
(with SubID = sub0)

When the first subscription request is received, the pubsub service creates 
a new affiliation of type none and a new subscription. Ralph said that he 
would use the bare JID (e.g. juliet at capulet.com) as the entity that now has 
an affiliation with the node and the subscription should keep using the 
provided JID (e.g. juliet at capulet.com/balcony). But as StPeter said using 
the bare JID might be correct for the IM world (i.e. human being users) but 
not fully correct when dealing with other type of entities.

When the second subscription request is received, the pubsub service has to 
find out who is the entity that is trying to subscribe to the node. As we 
said before, Ralph said that the bare JID can be used so we now know that 
the new subscription belongs to the same entity that made the previous 
subscription (e.g. juliet at capulet.com). This is fine for the IM world but 
not for other cases.

For the third subscription request the same steps we used for the second 
subscriptions are used. Therefore, if we were using the bare JID as the way 
to identify entities then the service will end up with only one affiliation 
for juliet at capulet.com and 3 subscriptions to different JIDs.

As you may have realized the problem is that we cannot trust that using the 
bare JID of the JID that is going to get the event notifications is the 
right way to identify the real entity that is behind the three 
subscriptions. IMHO, the options are 1) inferring who the affiliate is or 2) 
let the subscriber provide who the real entity/affiliate is thus making the 
relationship explicit. I think that using an explicit mode does not have any 
margin of error.

So my recommendation is to add a new attribute to the <subscribe> element 
that specifies the JID of the entity that owns the subscription. If the 
attribute is not specified then the JID used for the subscription is assumed 
to be the JID that uniquely identifies the entity. This idea should also 
work well for previous versions.

Examples of how this may work.

Example 1. Entity subscribes to a node (entity JID = subscription JID)
<iq type='set'
    from='francisco at denmark.lit/barracks'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        jid='francisco at denmark.lit'/>

Example 2. Entity subscribes to a node (entity JID that owns the 
subscription is made explicit)
<iq type='set'
    from='francisco at denmark.lit/barracks'
  <pubsub xmlns='http://jabber.org/protocol/pubsub'>
        owner='francisco at denmark.lit'
        jid='francisco at denmark.lit/PDA'/>

A pubsub service that is not very concerned about security might allow the 
owner to have a different bare JID to the subscription bare JID. This 
scenario might be useful for users that have different accounts in many 
servers. But the JEP may recommend that pubsub services should validate that 
the bare JID of the owner should match the bare JID of the subscription JID.

Regarding the way the pubsub service should expose affiliations and 
subscriptions I would prefer to split them and expose them as different 
things. This would make things simpler but may break existing 
implementations. But a consequence of  copying the affiliation for each 
subscription is that the node owner might potentially try to set a different 
affiliation in each subscription for the same entity. The service would need 
to validate this case and IMO the API is also confusing and error prone. And 
the way to fix that is to make the service more complex.


  -- Gato

"Bob Wyman" <bob at wyman.us> wrote in message 
news:089e01c634f0$7030f590$be43fa0a at BOBSLAPTOP...
> On Fri, Feb 17, 2006 at 09:22:30PM -0700, Peter Saint-Andre wrote:
>> So my conclusion is that it's best to be a bit more verbose and
>> represent one "affiliate" for each combination of affiliation and
>> subscription. This is more verbose but, I think, the safest approach.
> I agree. Given the way that current systems work and what we have in
> the current protocol, we must use the more verbose approach and support
> having multiple subscription-specific affiliations to a single node. The
> current mechanism for getting a list of active subscriptions is to list
> affiliations. It would be kind of violent to modify that now...
> I also agree with Ralphm's suggestion that mixing affliations and
> subscriptions is messy. I have never liked this "affiliation" business. It
> seems to combine too many concepts into a single messy framework. What I
> would much prefer is a general access control mechanism for operations on
> nodes. Doing things such as listing subscriptions shouldn't require that
> clients get exposed to "affiliation" information which is basically just
> access control info on nodes. When I'm working with subscriptions, I don't
> care about nodes... I only care about nodes when I'm creating 
> subscriptions.
> bob wyman

More information about the Standards mailing list