[Standards-JIG] pubsub: affiliations and subscriptions

Peter Saint-Andre stpeter at jabber.org
Sat Feb 18 04:22:30 UTC 2006


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

In chatting with Gaston Dombiak the other day, we discovered that there
is potentially a problem with the process for modifying affiliations in
pubsub when an entity has multiple subscriptions to the same node (which
we differentiate via SubIDs). Consider the following scenario:

0. juliet at capulet.com is subscribed with SubID = sub0

1. juliet at capulet.com is subscribed with SubID = sub1

2. juliet at capulet.com/balcony is subscribed with SubID = sub2

3. juliet at capulet.com/chamber is subscribed with SubId = sub3

So when the node owner requests the affiliations list for the node, what
gets returned? Option #1 is:

<entities>
  <entity jid='juliet at capulet.com'
          affiliation='none'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com/balcony'
          affiliation='none'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com/chamber'
          affiliation='none'
          subscription='subscribed'/>
</entities>

Unfortunately that doesn't differentiate between the subscriptions based
on SubID, so Option #2 is probably superior:

<entities>
  <entity jid='juliet at capulet.com'
          affiliation='none'
          subid='sub0'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com'
          affiliation='none'
          subid='sub1'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com/balcony'
          affiliation='none'
          subid='sub2'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com/chamber'
          affiliation='none'
          subid='sub3'
          subscription='subscribed'/>
</entities>

But, you might say, what we have here is one entity (juliet at capulet.com)
with one affiliation, who happens to have four subscriptions:

<entities>
  <entity jid='juliet at capulet.com'
          affiliation='none'
          subscription='subscribed'/>
</entities>

In other words, what we care about is that juliet at capulet.com has an
affiliation of "none" and has at least one subscription. This is Option #3.

Yet the pubsub service has no reliable way of truncating full JIDs
(node at domain.tld/resource) to bare JIDs (node at domain.tld) if it does not
perform service discovery -- just because a JID *looks* like the full
JID of a user doesn't mean that it *is* one (e.g., we could set up
pubsub chaining, whereby one node is subscribed to another node, and
pubsub nodes can be of the form service at domain.tld/NodeID). So the
service could send a disco#info request to the guessed-at bare JID; if
it gets back an identity of "account/registered", it can safely assume
that the affiliated entity can be stored as a bare JID (e.g., it would
truncate juliet at capulet.com/balcony to juliet at capulet.com, send a
disco#info request to juliet at capulet.com, get back a user identity, and
store the "affiliate" as juliet at capulet.com). At this point changing the
entity's subscription state to "none" would cancel out all of the
subscriptions.

Option #1 seems problematic, although it is implicitly what the JEP
describes today.

Option #2 seems a bit verbose, but safe.

Option #3 seems like an awful lot of work.

This may seem like an obscure edge case. But let's throw different
affiliations into the mix to show how messy this is. :-)

Now let's assume that each of these <entity/> elements has a different
'affiliation' value:

<entities>
  <entity jid='juliet at capulet.com'
          affiliation='owner'
          subid='sub0'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com'
          affiliation='owner'
          subid='sub1'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com/balcony'
          affiliation='publisher'
          subid='sub2'
          subscription='subscribed'/>
  <entity jid='juliet at capulet.com/chamber'
          affiliation='none'
          subid='sub3'
          subscription='subscribed'/>
</entities>

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.

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

iD8DBQFD9qEFNF1RSzyt3NURAv0gAJkB+SeQy9ZO8+huZ7RoQ9TKn5feZwCcDkAd
L6N86fr3FxCMnYHf/+yGfZo=
=rNGw
-----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/20060217/5f1b135b/attachment.bin>


More information about the Standards mailing list