[Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)

Ralph Meijer jabber.org at ralphm.ik.nu
Mon Mar 22 16:59:20 UTC 2010

Jumping into this thread at random, I hope to address some of my
concerns towards iq-based notifications in XEP-0060.

On Thu, 2010-02-18 at 19:47 -0700, Peter Saint-Andre wrote: 
> On 2/18/10 5:02 PM, Fabio Forno wrote:
> > On Fri, Feb 19, 2010 at 12:10 AM, Tuomas Koski <koski.tuomas at gmail.com> wrote:
> >>
> >> I have to admit that I have forgotten these use cases too. How ever
> >> here are my reasons why I'm sending events in IQs:
> >>  * to be 100% sure that the events don't go to offline storage
> >>  * To have "acks" without implement XEP-0184 Message Receipts or similar
> >>  * I'm connected with a JID with multiple resources (/a and /b for
> >> example). I want to send events only to resource /a. When the
> >> resource /a for some reason disappears some servers starts to route
> >> message stanzas sent to resource /a to resource /b.
> But you could do that with XEP-0079. ;-)
> I'm joking. Those do seem like valid reasons.

Even though Peter mentioned this jokingly, I'm very curious about /why/
Advanced Message Processing (XEP-0079) hasn't been picked up. I think it
potentially addresses some of the mentioned issues and is already
mentioned in section 12.5 of XEP-0060. It allows an entity (like a
pubsub service) to mention that it wants a message to be dropped or have
the recipient's server send back notifications or errors based on a set
of rules. This can be based on where it would be delivered to, or time
(timeout), or future extensions.

I can think of some reasons AMP hasn't been picked up:

1) AMP requires the session manager (or equivalent) to read into the
stanza beyond just the attributes on the outer element (to, from, type).
2) AMP is incomplete, badly architected
3) Does not actually address all issues IQs would solve
4) AMP is not implemented by servers and/or pubsub services

For 1, I'd love to see some opinions. I think ejabberd has implemented
AMP. We are also have some other proposed extensions that do delivery
magic, like SIFT, so this might actually not be really hard to do. I
just don't know.

For 2, I'm curious for opinions, too. I don't believe it is inherently
bad, and like to resolve whatever issues are there.

For 3, let's figure out those use cases, and see if it makes sense to
address that in XEP-0079.

For 4, chicken/egg of course, but adding support for this in Idavoll is
probably not very difficult and something I would look into if

AMP doesn't address lost messages or iq responses, but I believe that if
you need that kind of reliability, you probably need a transactional
system with n-phase commits anyway. I do believe that it addresses the
same use cases as iq-based notifications would, plus more, even though
not now.

> > Tuomas has been quicker than me. I confirm all the points, plus:
> > - even xep-184  does not guarantee reliability in a s2s scenario
> There are no *guarantees* of reliability even with IQs. The question is:
> how much reliability do you need, and does the use of <iq/> for
> notifications achieve that?
> > - in case of high throughput <iq/> delivery has implicit control flow
> > management, as for IBB
> Yes, that's a nice side-benefit.

>From a pubsub service point-of-view, this is actually not a very nice
property. It requires the whole notification delivery mechanism to
implement delivery queues with retries (for stuff that might actually
have been received all right) and back-off algorithms. Basically turning
a fire-and-forget system into a store-and-forward one.

> > - I don't see many compatibility issues, since <iq/> delivery is a
> > config option which must be turned on
> I think Kev is concerned about compatibility on the client side. The
> admin can enable <iq/> delivery on the service but a client might not be
> able to handle the notifications because it is expecting <message/>
> stanzas, not <iq/> stanzas. In that case the client will presumably
> return an IQ error.

As mentioned before, this is not so much a problem if the client needs
to turn it on anyway. Message-based delivery would be a MUST support (if
notifications are supported).

What I am a bit wary of, is that applications will start using it as the
default mode, which creates an unnecessary burden on services for 90% of
the use cases. IQ semantics do require more traffic, more processing and
more memory usage. Given that the major selling point has mostly been
'reliability' and most uses of pubsub don't really need that, I would
rather not see this getting into XEP-0060.

> > - yep, it works just with presence subscriptions to the pubsub nodes,
> > but one of the features I usually miss in standard pubsub services for
> > real applications is a decent handling of presence subscriptions
> I'm not sure how that's connected to <iq/> delivery.

Agreed. Presence subscriptions are a separate feature, solving other use


More information about the Standards mailing list