[standards-jig] JEP-0060 Pub/Sub, subscriptions and configuration

Ralph Meijer jabber.org at ralphm.ik.nu
Mon Apr 21 19:57:48 UTC 2003


While reading the JEP I noticed the following about subscriptions and their
(possible) configuration:

You can for example subscribe as both ralphm at ik.nu and as ralph at ik.nu/foo from
a client connected as ralphm at ik.nu/bar (example 21) because of the jid
attribute to <subscribe/>. However, the <options/> element does not have
that attribute, and because of that, you can't configure them as separate

After some discussion with pgmillard in the jdev room, my proposal is to
make <options/> behave like <subscription/> and have a required jid attribute
for <options/>. Having it optional makes it all to ambiguous.

Also, example 38 gives a mismatch to the schemas at the end of the JEP: there
are two children of <pubsub/> now. What we could do is alter example 38
into the following:

<iq type="result" from="pubsub.jabber.org" to="sub1 at foo.com/home" id="sub1">
  <pubsub xmlns="http://jabber.org/protocol/pubsub">
    <entity jid="sub1 at foo.com" affiliation="none" subscription="subscribed">

The <options/> of course indicating that configuration is required.

Thinking about this, we have four states of subscription now:


The last state is one in which you won't get notifications. So are you really
subscribed? And if you forget to configure, how can you see that? Retrieving
the affiliations as in example 31/32 doesn't reveal that fact, because it would
show as 'subscribed'. My suggestion is to add the fourth level of subscription
'unconfigured'. An entity has to examine the subscription attribute of the
iq-result anyway, to see if it is 'pending' or 'subscribed'.



More information about the Standards mailing list