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

Ralph Siemsen ralphs at blueairnetworks.com
Mon May 27 19:38:23 UTC 2002

Ralph Meijer wrote:

 >> Since then, however, I've learnt quite a bit about pub/sub, and
 >> I'm not sure that the ENS is the best solution for Jabber, even
 >> though it is an excellent choice for certain applications (pure
 >> event-based systems).
 > I am not sure which, if any, is the best. Just like you I think we should
 > have more discussion on this, if only to get at least one of the two
 > approved. My reasons for writing this piece was to possibly get some
 > concensus and fill in possibly missing stuff.

Another vote for more discussion!  I think both JEPs are interesting but
they need to be harmonized.  By this I mean to take the best features of
each and combine them into a single effort, that will hopefully suit
everyone's needs.

JEP0021 is easy to understand though (KISS principle), however the 
overloading of JID seems like a limitation.  The namespace proposal in 
JEP0024 seems more flexible, especially the ability to subscribe 
selectively to general event categories.  But IMHO the option for 
"relative" versus "absolute" subscriptions adds too much complexity - 
just a simple "add" or "remove" will do, along with "remove all".

The notion of Delivery Sensitivity put forth in JEP0024 is also very 
important.  Since presence of an entity is one of the cornerstones of an 
IM system, it makes sense make this information readily available to 
consumers. It also makes it possible to write many other 
presence-sensitive services on top of Jabber, without requiring the user 
to subscribe each one (and thereby clutter up their roster).

The s2s considerations in JEP0024 are excellent, however I can't help 
but think that they should form a JEP of their own (perhaps relating to 
the multicast JEP?).  Perhaps a first goal should be to get a common 
standard for single-host pub/sub, since that is probably the most widely 
deployed form.

 >>> <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.
 >> I tend to agree. See JEP-0021, section 6.2.

Agreed as well.

 >>> 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 jabber server does quite a few interesting things to JIDs, I've
noticed.  Kinda not the sort of thing I expect from an XML router,
actually.  Not sure if these are simply bugs in the server or real
design features.  A successful pubsub proposal will have to live with 
these limitations unfortunately, unless they can be solved in jabberd 
wihtout breaking backwards compability.

 > On the subject of using <iq/>s and the longevity of subscriptions,
 > my attention was drawn to the last sentence in section 3.5 of
 > JEP-0021 that states:
 > "If the subscriber responds to the notification with an error, the
 > subscriber will be automatically unsubscribed from the event by the
 > ENS."
 > Such an error response also occurs when a <iq type='set'/> is sent
 > to a non-connected subscriber. This effectively means that a not so
 > frequently connected subscriber will probably get unsubscribed very
 > soon.

I think coupling in presence notification from the server is the way to
go here - eg. keep all of the guesswork about who is online in one spot.
When a user becomes unavailable, the pubsub component can drop them.
But the pubsub component should not be making its own decisions about a 
user being onling or not.

What about JEP0028?  It is very incomplete, thought I am guessing that 
there is more (undocumented) knowledge living in at Jabber Inc. that 
really would like to be shared *smile*...


More information about the Standards mailing list