[Standards-JIG] pubsub: affiliations and subscriptions

Peter Saint-Andre stpeter at jabber.org
Wed Apr 5 22:41:20 UTC 2006

Hash: SHA1

Peter Saint-Andre wrote:
> Ralph Meijer wrote:
>>> On Fri, Feb 17, 2006 at 09:22:30PM -0700, Peter Saint-Andre wrote:
>>>> [..]
>>>> I think we'd agree that the same entity can have only one affiliation
>>>> (e.g., we can't have more than one <entity/> element with a JID of
>>>> juliet at capulet.com and different values for the 'affiliation' attribute).
>>>> If we "reduce" all the full JIDs to bare JIDs in the foregoing example,
>>>> we'd have one "affiliate" but we'd be unable to differentiate between
>>>> different affiliations for different resources.
>>>> 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 believe up to now, we assumed that affilations are always based on the
>>> bare JID. If you want to have node chaining, the pubsub service should
>>> just subscribe to the proxied node with its own bare JID and store the
>>> correct routing itself (possibly in the local node's configuration).
>>> Nevertheless, I would love to move away from this coupled affilation and
>>> subscription mess. That is, instead of <entities/>, have separate
>>> elements for dealing with affiliations and subscriptions. This makes the
>>> protocol easier to implement and causes a lot less headache.
> OK, since we seem to have consensus on this, I'll work up a fix in
> 1.8pre12 (I'm going to publish 1.8pre11 with a bunch of smaller fixes
> here in a minute).

I have endeavored to incorporate this feedback. Here is an overview of
the changes:

1. <entities/> and <entity/> (dual-purpose for affiliation and
subscription retrieval and management) are gone. Instead we have...

2. <subscriptions/> (qualified by pubsub namespace) is used to retrieve
subscriptions at a service, each subscription is captured with an
<subscription/> element that has the following attributes: 'jid',
'node', 'subid', and 'subscription' (values: pending, subscribed,

3. In response to a successful subscription, the service returns a
<subscription/> element with 'jid', 'node', 'subid', and 'subscription'
attributes (not an <entity/> element since we've done away with that).

4. <affiliations/> (qualified by pubsub namespace) is used to retrieve
affiliations at a service, each affiliation is captured with an
<affiliation/> element that has the following attributes: 'jid', 'node',
and 'affiliation' (values: outcast, owner, publisher).

5. <affiliations/> (qualified by pubsub#owner namespace) is used to
manage affiliations for a node, each affiliation is captured with an
<affiliation/> element that has the following attributes: 'jid' and
'affiliation' (values: outcast, owner, publisher).

The CVS diff is here:


If we can gain consensus on these changes, I will publish 1.8pre12
(after reading through my four remaining pubsub-related email messages
and making sure that I've incorporated all feedback received so far).



- --
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/20060405/e486e351/attachment.bin>

More information about the Standards mailing list