[Standards] XEP-0184 business rules for message receipts

Kevin Smith kevin at kismith.co.uk
Fri Mar 12 23:29:30 UTC 2010


Some tweaks, as I think the "Don't use lack of a receipt to mean you
should resend" applies across the board (indeed, your earlier summary
had this explicitly, but the proposed text doesn't).

On Fri, Mar 12, 2010 at 11:02 PM, Peter Saint-Andre <stpeter at stpeter.im> wrote:
> 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

"MAY request a receipt", I think. It's entirely legitimate for a
client to support -184, and to never request a receipt, only supply
them.

> 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

"MUST NOT 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).

Then that bit can be scratched.

> 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.
>
> ***
>
>

Otherwise good, thanks.

/K



More information about the Standards mailing list