On Fri, Mar 12, 2010 at 3:32 AM, Peter Saint-Andre <[email protected]> wrote: >> Ok, so... >> I think >> "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." can be more >> explicit and say what this really means, something like " As such it >> is NOT RECOMMENDED that a client uses the lack of a delivered receipt >> as an indication that a message has not been received, or should be >> retransmitted". > > Erk, too many nots. :) > > How about: > > "A sender cannot know whether a recipient supports this protocol if the > sender knows (or addresses messages to) only the recipient's bare JID. > In this case the sender MUST NOT consider the lack of a receipt as an > indication that the message needs to be retransmitted."
My precious double-negatives! Actually, the meaning of the two versions is slightly different - the latter suggests you don't use the lack of a receipt as a suggestion to retransmit when sending to the bare JID. I'm suggesting that the text about limitations suggests the same for a full JID. How about "A sender cannot know whether a recipient supports this protocol if the sender knows (or addresses messages to) only the recipient's bare JID, and cannot know if a supporting recipient will return a receipt. As such, the sender MUST NOT consider the lack of a receipt as an indication that the message needs to be retransmitted." >> "A sender MAY include a request for message receipts even if it has >> not been able to determine if the intended recipient supports message >> receipts. This can be done directly via Service Discovery or >> indirectly via Entity Capabilities." + "but MUST NOT include a >> request where it has been able to determine that the intended >> recipient does not support message receipts" or such would solve a lot >> of my above issues. > Indeed. I'll reworking the text along the lines you propose and post again. Wonderful, thanks. /K
