[Standards] XEP-0184 business rules for message receipts

Peter Saint-Andre 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
>>> 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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6820 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20100312/cd0a4957/attachment.bin>


More information about the Standards mailing list