[Standards] reliable messaging
stpeter at stpeter.im
Wed Jun 17 16:07:31 UTC 2009
-----BEGIN PGP SIGNED MESSAGE-----
On 6/17/09 7:59 AM, Kevin Smith wrote:
> On Wed, Jun 17, 2009 at 2:55 PM, Evgeniy Khramtsov<xramtsov at gmail.com> 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
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
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
5. We simply can't solve for broken endpoints.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
-----END PGP SIGNATURE-----
More information about the Standards