[standards-jig] Publish/Subscribe, merge of JEPs 0021 and 0024

DJ Adams dj.adams at pobox.com
Tue May 28 08:28:03 UTC 2002

On Thu, May 23, 2002 at 07:07:54PM +0200, Ralph Meijer wrote:
> Hi,
> It has been a while now since two JEPs were submitted on the subject of
> publish/subscribe (pubsub). There has been a lot of discussion, but recently
> that seems to have come to a halt. This e-mail is an effort to get the
> discussion going again and maybe merge the two JEPs. In the following I will
> set out my views of the differences and similarities, pros and cons. This
> e-mail isn't an essay, so it'll be as short as possible. 

Hi Ralph, hi everyone

Your efforts are appreciated, Ralph - thanks!

I'll just reply to the bits as they come up in reading this sequentially,
to start off with.

> Differences
> ===========
> Terminology and qualification:
> - JEP-0021 is about events (qualified by a JID) that entities can be notified
>   of (notifications) by the Jabber Event Notification Service, a Jabber server
>   component that manages the subscriptions and distribution of those
>   notifications.
> - JEP-0024 talks about information (to be) published. These are qualified by a
>   namespace and the component is simply called pubsub component.

True, although (perhaps not stated explicitly in the JEP) 0024 can also 
send events, i.e. a sending-qualified-by-something-but-without-a-payload,
in that you can send a publish with no payload. 

> In JEP-0024 one entity can publish information with different qualifications.
> These qualifications are in one place (the namespace) and all data is in
> the payload. By whom the information has been published is clearly separated
> from the qualification by use of a 'from' attribute to the <publish/>
> element.

Just a note - this is added by the pubsub component before pushing the
published data out to the subscribers. It's not put on there by the 
publisher itself (although the publisher will put a from attr in the 
outermost <iq> tag, of course, if it's a component). 

> <auth-info/> is for authorising subscriptions. The example given is not
> correct as far as I can tell, but that is besides the point. The idea is that
> you can send some credentials along with the subscription to be allowed to
> subscribe to a certain event. JEP-0024 lacks this unfortunately. We should
> think about how to do this, because you could possibly need to communicate
> with the publisher(s) about the authorisation.

I think it's at least worth thinking about, although originally I had the
idea that the control over who got to subscribe to what would be at a higher
granular level; for example, a publisher who wanted to restrict access to
what they were publishing would use a specific pubsub component that had
some sort of access control in front of it (e.g. achieved by a component

> As response to a succesful subscription you get back the <subscribed/>
> element. An unsuccesful subscription returns a <subscribe> element. My opinion
> here is that it is not really useful to define a different element for this
> and that a <subscribe/> would do just fine in both cases.

Well, as far as I can see from the 0021 spec, it looks fine and is the
'classic' way of doing things - you send a packet - something goes wrong - 
you get what you sent returned to you, with an extra error attachment. This
is what (I assume) Rob is showing here. (Rob?)

> <reliable/> is to 'ensure' that all subscribers get the notification
> eventually (by resending it upon failure). JEP-0024 also lacks this, but I
> think QoS is outside of the scope of pubsub and should be solved in the jabber
> core.

Yes, indeed. In the same way that I personally think that data storage and
forwarding should be separate to pubsub, so I also think that QoS type stuff
is independent of pubsub. (The same could be argued for access control too).

> JEP-0024 talks about proxying pubsub. I think this is a good way of preventing
> unnecessary traffic. JEP-0021 lacks this, and because of the use of JIDs
> for qualifying the events, I think it is not possible to do this the
> same way without losing information on the publisher. Also we might review
> this part in light of the brand-new JEP-0033 about optimizing packet traffic.
> Although it (JEP-0033) states that the application of 'headers' are unlikely
> to be useful, pubsub might be just that area in which it is useful.

Yes, although I can't immediately see where there would be a clash between
the two. 

> Both JEPs use <iq/>s to publish information. I have been playing a bit with
> a pre-JEP-0024 pubsub implementation by DJ and have noticed the following
> about routing of <iq/> packets. First, if a <iq/> is sent with a 'from'
> attribute that has no resource part, the JSM rewrites this to a JID with
> the resource part of your current connection added. This makes it unpossible
> to subscribe without supplying a resource, although JEP-0024 suggests it is.

We were careful not to exclude components from the pubsub game in 0024.
That means, a pubsub subscriber can be a component - it doesn't have to 
be a JSM user. Similarly, a pubsub publisher can be a component, or a 
JSM user.

> The other thing is that you cannot receive published information when you
> are not connected because currently there is no store and forward for <iq/>s
> (apart from dj's hack). So subscribers that only connect occasionally still

Well, as mentioned above, I think the issue as to whether, how, and when
IQs should be stored and forwarded must be addressed independently of 
pubsub (although you were right to bring the point up). This issue applies
equally to iq:rpc. After the first JabberConf, Jer and I (and others) talked
about how this might be achieved. As you've mentioned, I've already done
some experimental hacks, but Jeremie's had some nicer ideas (what's new? ;-)
more recently. I guess we should start a separate thread for that.

> potentially attract a lot of useless traffic when not subscribing to the
> presence of the pubsub component also. Or the client has to subscribe
> and unsubscribe each session. Or do subscriptions end with the session end?

There's no concept of session-specific subscriptions in 0024. That said,
I've seen a couple of implementations / descriptions of pubsub in other 
areas, both of which by default expire the subscription after X hours. 
I'm not sure I like this approach (whereby the subscriber keeps having to
resubscribe) but I think it's relevant to this theme. Basically, regarding
presence subscriptions, in 0024, if you want only to receive stuff when you're
online, then set up a presence relationship with the pubsub component. 
Otherwise, you'll get everything. That's not to say that there aren't 
other ways to stop you getting stuff - you could set up a message filter to
throw away stuff from the pubsub component if you were offline, or something.



More information about the Standards mailing list