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

Ralph Meijer jabber.org at ralphm.ik.nu
Thu May 23 17:07:54 UTC 2002


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. 

The JEPs in question are JEP-0021 (Jabber Event Notification Service (ENS))
and JEP 0024 (Publish/Subscribe) and touch the same subject, using somewhat
different terminology at times which I will expand on later.


  - are about pubsub.
  - have a component that manages the subscriptions and distribution of
    published items.
  - use <iq/> for both subscription and publishing.
  - feature no direct communication between publisher and subscriber.


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
- JEP-0024 talks about information (to be) published. These are qualified by a
  namespace and the component is simply called pubsub component.

The fact that JEP-0021 uses JIDs for qualifying the events being published
(and expects the publisher to publish these events from that JID) divides the
information so that it is to be found in several places: somewhere in the
origination JID (user part, hostname (sub-)part and resource) and in the
optional payload of the notification. Also, when using a simple JSM client as
publisher, you are limited somewhat in using those places for putting
information. Furthermore, you'd have to add a namespace declaration on
possible payload to adhere to the XML standard. This means that when you want
to send information in the payload of the notification you have somewhat
redundant data (information is never redundant): the qualification of the
event and the namespace(s) of the 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/>


JEP-0021 has two possible children of the <subscribe/> element which I will
discuss in turn.

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

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.

<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


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.

Other notes:

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.

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
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?

This is what I could come up with right now. In JEP-0024 terms:

<iq type='set' to='pubsub.jabber.org' from='ralphm at ik.nu/Home'>
  <query xmlns='jabber:iq:pubsub'>



More information about the Standards mailing list