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

Pedro Melo melo at simplicidade.org
Fri Feb 19 10:51:35 UTC 2010


On Fri, Feb 19, 2010 at 9:06 AM, Joe Hildebrand
<joe.hildebrand at webex.com> wrote:
> On 2/19/10 12:47 AM, "Evgeniy Khramtsov" <xramtsov at gmail.com> wrote:
>> Pedro Melo wrote:
>>>> There are a myriad of ways the original IQ or the ack could get lost.  My
>>>> point is that the response does not serve any value to the sender, since I
>>>> don't believe there is anything useful to be done when the sender does not
>>>> receive the ack.  Resending is almost always going to be wrong.
>>> Why? I think the exact opposite is true. We have item ID's so we can
>>> ignore duplicates.
> So you retry, and don't get a response.  What now?  Retry?

Yes. Probably with a exponential back-off and with a retry limit.
Also, a good pubsub implementation would skip sending further
notifications to this JID until he does get a reply.

It really depends on the contract (and I use this in a liberal way)
the client has with the pubsub service in question.

If I subscribe a service via pubsub from a provider for a topic that
is critical to me, I expect the pubsub implementation to try its
hardest to deliver my notifications. The provider might require extra
fees for this type of service for example (and we can finally see
<payment-required xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/> in the
real world), thats ok.

What I'm trying to say is that I don't want to limit potential uses of
this, <iq>-based delivery. So the policy of retries should be
suggested but leave space for per-deployment adjustments.

Getting your real-time-fix of RSS will probably need different
policies than a stock ticker.

> Let me ask a different question.  What are you going to do if you get a
> response?

It the pubsub gets a <iq type="result">? Then the delivery was
successful. If we get a error, then it depends if it is a recoverable
or temporary error condition, or permanent.

>> I guess because if a sender doesn't receive the response, this doesn't
>> mean a receiver doesn't receive the request.
> Yes, although Pedro has a point that the id's allow you to discard
> duplicates.


Pedro Melo
xmpp:melo at simplicidade.org
mailto:melo at simplicidade.org

More information about the Standards mailing list