Nice sunday for all, On 27 February 2010 06:26, Peter Saint-Andre <[email protected]> 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 >>> <[email protected]> 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
