[Standards-JIG] RE: pubsub: affiliations and subscriptions
jean-louis.seguineau at laposte.net
Wed Feb 22 12:07:24 UTC 2006
Interresting approach, indeed.
But I support Ralph and Bob in saying that mixing access control
(affiliation) and subscription is messy.
Affiliation is all about making sure the right party is performing the
Susbcription is about defining the 'interest' (i.e. the what?) and the
destination of the notification (the where?).
The issue comes from the way JIDs (i.e. communication handles) are used to
convey authorization semantic. That may work to a certain extent in the
context of an IM server, but become a little stretched for additional
services such as PubSub or MUC.
Recognizing that affiliation and subscription (to pubsub or a room) are two
different concerns will help finding an appropriate answer.
I believe that the way to convey the 'membership' to a particular
affiliation must be opaque to the subscriber, maybe using some kind of token
to allow the implementation to reconcile affiliations. Gaston's approach
could then be used in order to convey this token instead of JID in the owner
attribute of the <subscribe/>.
Using a separate element to describe affiliation would in principle be
compatible with existing implementations, as they should not giver any
meaning to unknown extensions. This approach would also pave the way for a
more appropriate approach to 'security' than just making sure JIDs are the
same in the subscription and the info-query....
Date: Tue, 21 Feb 2006 18:27:55 -0300
From: "Gaston Dombiak" <gaston at jivesoftware.com>
Subject: [Standards-JIG] Re: pubsub: affiliations and subscriptions
To: standards-jig at jabber.org
Message-ID: <dtg0kv$57m$1 at sea.gmane.org>
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)
from='francisco at denmark.lit/barracks'
jid='francisco at denmark.lit'/>
Example 2. Entity subscribes to a node (entity JID that owns the
subscription is made explicit)
from='francisco at denmark.lit/barracks'
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.
"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
> bob wyman
More information about the Standards