[Standards] XEP-0184 business rules for message receipts

Tuomas Koski koski.tuomas at gmail.com
Sun Feb 28 12:44:43 UTC 2010


Nice sunday for all,

On 27 February 2010 06:26, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 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?

+1

Cheers,
--
Tuomas



More information about the Standards mailing list