[Standards-JIG] pubsub: affiliations and subscriptions

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


-----BEGIN PGP SIGNED MESSAGE-----
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,
unconfigured).

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:

http://www.jabberstudio.org/cgi-bin/viewcvs.cgi/cvs/jeps/0060/jep-0060.xml?r1=1.108&r2=1.109

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

Thanks!

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

iD8DBQFENEeQNF1RSzyt3NURAlb6AJ9EyYUCBtP0ff5ZLqnu612raaSKcgCg0tdy
ziDGuN5FYyamc4tI6/q0Elo=
=SJrl
-----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/20060405/e486e351/attachment.bin>


More information about the Standards mailing list