On 3/12/10 1:00 AM, Kevin Smith wrote: > 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."
You're right that there are two instances of ignorance: (1) blindly sending to the bare JID (2) sending to the full JID without first performing disco#info or receiving caps data. I think we wan to say that #1 is OK but you're on your own, and #2 is discouraged because you have disco/caps at your disposal. There is a third case of (3) the disco/caps data shows that the intended recipient's full JID does *not* support receipts; in this case I think we want to say that you SHOULD NOT request receipts. And, in all of these cases, you MUST NOT take the lack of a receipt as a trigger for resending the message. /psa
smime.p7s
Description: S/MIME Cryptographic Signature
