[Standards] XEP-0184 business rules for message receipts

Peter Saint-Andre stpeter at stpeter.im
Sat Feb 27 05:26:38 UTC 2010

On 2/25/10 5:58 AM, Peter Saint-Andre wrote:
> On 2/25/10 3:29 AM, Fabio Forno wrote:
>> On Wed, Feb 17, 2010 at 3:35 PM, Jonathan Schleifer
>> <js-xmpp-standards at webkeks.org> wrote:
>>>>  2. A sender SHOULD NOT include a request for message receipts unless
>>>> it knows (via Service Discovery [4] or Entity Capabilities [5]) that the
>>>> intended recipient supports the protocol described herein or unless the
>>>> use of message receipts is negotiated via Stanza Session Negotiation [6].
>>> I agree that those two are not too useful. It might be desirable to send to
>>> the bare JID when the user's offline and get a receipt once he gets online
>>> again.
>> Just a quick note about the "reliability" note. These modifications
>> suit better  the semantics of message stanzas, but we also accept that
>> we can miss receipts for messages which are actually delivered (just
>> to remember that when we need a prompt ack from an online resource iq
>> pubsub events work better).
> That's a good point. Currently XEP-0184 doesn't provide very helpful
> advice about how much reliability you can expect from message receipts.
> I think we can improve the text in that note. Suggestions welcome. :)

I propose that we split this into its own section:


3. Reliability

This document defines a protocol that enables a sender to ask the
recipient to return a receipt for a message. Although the return of a
message receipt lets the sender know that the message has been
delivered, there are many reasons why the sender might not receive a
receipt immediately or at all, including but not limited to the following:

    * The recipient (or the particular intended resource to which the
sender addressed the message) does not in fact support message receipts.
    * The intended resource supports message receipts but the
recipient's server delivers the message to another resource that does
not support message receipts.
    * The recipient's client receives the message but experiences a
malfunction before generating a receipt.
    * The recipient returns a receipt but the receipt is lost on the way
back from the recipient to the sender (e.g., because of connectivity
issues or software failures at any hop).

Therefore this document does not define a protocol for complete
reliability or guaranteed delivery, and those who implement and deploy
this protocol need to be aware of its limitations.


Is that text acceptable?


Peter Saint-Andre

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100226/d2ffac00/attachment.bin>

More information about the Standards mailing list