-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 9/18/09 1:52 PM, Fabio Forno wrote: > On Fri, Sep 18, 2009 at 7:48 PM, Kevin Smith <[email protected]> wrote: >> On Thu, Sep 17, 2009 at 3:20 PM, Fabio Forno <[email protected]> wrote: >>> See the other thread (I was late in the reply sorry): I plan to make >>> it available only with presence subscriptions. >> Is there a rough agreement that the 'real' solution here, in the >> perfect world of having all XEPs available to us, would be 198 for >> reliable delivery, and message expiration in the events? Not arguing >> for or against hashing out something that would work Right Now, but >> it'd be good to be clear about what the ideal would be (and how far >> away from it we are). > > Well, while I'm 100% sure XEP-198 is the solution for the last hop > (especially for session recovery which would save tens of KBs each > reconnection), I'm not sure that for this specific case it works as > fine as an <iq/>. From my point of view the reason is simple: we must > use three XEPs (99, 184, 198) to replicate the exact semantics of an > <iq/> with a <message/> stanza, i.e. we must do a difficult thing for > reinventing an easy one which already exists. As far I know the only > objection against an <iq/> option for delivery is that it works only > with presence subscriptions, which is not a big deal imho (I can't > imagine a scenario where we want reliable delivery to a given client > and no presence subscription)
Well, presence itself is not completely reliable, but with IQ you'll receive a bounce from the recipient's full JID. Given the assumption of presence subscriptions, I have no problem with IQ delivery. Peter - -- Peter Saint-Andre https://stpeter.im/ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAkqz6pAACgkQNL8k5A2w/vwrewCg6KxVgLQLWUWg+CESOdf3AG+m rGYAn3z0/PLnt2QIwah7x06jCfOZ6T5R =StNN -----END PGP SIGNATURE-----
