[Standards] XEP-0184 business rules for message receipts

Peter Saint-Andre stpeter at stpeter.im
Fri Mar 12 23:02:46 UTC 2010


On 3/12/10 7:55 AM, Peter Saint-Andre wrote:
> On 3/12/10 6:24 AM, Kevin Smith wrote:
>> On Fri, Mar 12, 2010 at 1:20 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
>>> 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.
>>
>> That's exactly what I meant, thanks.
> 
> Super. I'll try to find some time today to clean up the spec.

Here is my proposed text, which is contained in a completely new section:

***

5. When to Request Receipts

A sender could request receipts on any non-error message (chat,
groupchat, headline, or normal) no matter if the recipient's address is
a bare JID <localpart at domain.tld> or a full JID
<localpart at domain.tld/resource>. Whether it is appropriate or advisable
to do so it another question. This section provides recommendations
about when and when not to request receipts, and what results to expect
in each scenario.

5.1 Bare JID

If the sender knows only the recipient's bare JID, it cannot cannot
determine (via disco or caps) whether the intended recipient supports
message receipts. In this case, the sender MAY request a receipt when
sending a message of type "chat", "headline", or "normal" to the
recipient's bare JID. However, the sender MUST NOT depend on receiving a
receipt and MUST NOT resend the message if it does not receive a receipt.

5.2 Full JID

If the sender knows a full JID for the recipient (e.g., via presence),
it SHOULD attempt to determine (via disco or caps) whether the client at
that full JID supports message receipts before attempting to request
receipts. In this case, if the sender determines that the recipient's
client supports message receipts then it SHOULD request a receipt when
sending a message of type "chat", "headline", or "normal" to that full
JID. The sender MAY depend on receiving a receipt and MAY resend the
message if it does not receive a receipt within some configurable
timeout period (however, resend logic is out of scope for this
specification). If the sender determines that the recipient's client
does not support message receipts then it SHOULD NOT request a receipt
when sending a message to that full JID and MUST NOT resend the message
if it does not receive a receipt.

5.3 Groupchat

It is NOT RECOMMENDED to request a receipt when sending a message of
type "groupchat" in a Multi-User Chat [6] room because the logic for
determining when a message is truly "received" by all of the room
occupants is complex and because the sender would receive one receipt
from each occupant of the room, thus significantly increasing the number
of messages sent through the room.

***

-------------- 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/76821555/attachment.bin>


More information about the Standards mailing list