[Standards] XEP-0184 business rules for message receipts
stpeter at stpeter.im
Fri Mar 12 13:20:14 UTC 2010
On 3/12/10 1:00 AM, Kevin Smith wrote:
> On Fri, Mar 12, 2010 at 3:32 AM, Peter Saint-Andre <stpeter at stpeter.im> 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
>> 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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
More information about the Standards