-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 6/17/09 7:59 AM, Kevin Smith wrote: > On Wed, Jun 17, 2009 at 2:55 PM, Evgeniy Khramtsov<[email protected]> wrote: >>> How? If the client is broken, you have no way of knowing that it's not >>> sending message receipts in error. >> Message receipts in error? What do you mean? > > If your message isn't processed due to an internal client error, how > are you able to trust that the client knows that it wasn't processed, > and doesn't just send a receipt blindly? > > This is a fairly pointless aside, though - as previously noted in the > thread, you can't use Message Receipts for client to client > reliability.
I love these threads that happen while I'm asleep. :) A few comments... 1. My first email was off-the-cuff. I can write up a small XEP about this topic that describes things a bit more formally. 2. I don't think that we're attempting to define 100% reliability for XMPP messaging. 3. I agree with Nyco that so-called "whitespace pings" are really keepalives, and I'll adjust the 3920bis text accordingly. These keepalives help to figure out if a stream is idle (especially in the absence of stream management). 4. If a client needs to check end-to-end connectivity, it can use XMPP pings. This mechanism is not per-message but provides information about the reliability of the complete transport from one client to another. 4. I agree that message receipts do not provide information about the transport layer. 5. We simply can't solve for broken endpoints. Anything else? 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 iEYEARECAAYFAko5FMMACgkQNL8k5A2w/vwIjQCgpCMvfWr04u28BwSz/Fs7xOYn YTUAmweZW3u8tCrHgVsXz9EVEKLnKPqJ =RkJg -----END PGP SIGNATURE-----
