[Standards] reliable messaging

Brian Cully bcully at gmail.com
Wed Jun 17 14:13:23 UTC 2009

On 17-Jun-2009, at 09:59, 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.

	Don't get me wrong, I agree that there are no perfect guarantees.  
However, I think focusing too much on that is distracting. While you  
can never know for sure you can establish a certain amount of trust.  
Message ACKs are one such way to show that odds are better than normal  
that your message was received.

	If one were to go so far as to cryptographically sign the message  
receipt in some way (especially with a signature based on the contents  
of the original message) you've gone another step to show that the  
client got the message and processed it in some way. I'd venture to  
say that for most scenarios that kind of receipt would be more than  
good enough.


More information about the Standards mailing list