[Standards] IQ Pubsub again (was Re: Fwd: Meeting minutes 2010-02-15)
stpeter at stpeter.im
Mon Mar 29 17:50:52 CDT 2010
On 3/22/10 10:59 AM, Ralph Meijer wrote:
> 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.
AMP would be very nice, but it's not implemented in servers today,
whereas IQ support is universal.
> 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.
I think those who have advocated IQ-based notifications would argue that
waiting until AMP has been implemented and deployed more widely would
cause unnecessary (perhaps interminable) delays. Given that XEP-0079 was
advanced to Draft in October 2004 and still has not been implemented in
more than one or two servers, I would tend to agree.
>>> 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.
That seems to be a tradeoff that some pubsub implementors are willing to
risk, at least experimentally in order to gain more experience with
>>> - 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.
I agree that relatively few pubsub applications need IQ-based
notifications. Perhaps we need two things:
1. A clearer description of the use cases that truly need IQ-based
2. An applicability statement that strongly discourages IQ-based
notifications unless absolutely necessary.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards