[Standards] reliable messaging

Peter Saint-Andre stpeter at stpeter.im
Wed Jun 17 16:07:31 UTC 2009

Hash: SHA1

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
> 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 Saint-Andre

Version: GnuPG v1.4.8 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org


More information about the Standards mailing list