[Standards] XEP-0184 business rules for message receipts

Peter Saint-Andre stpeter at stpeter.im
Fri Mar 12 22:47:43 CST 2010


On 3/12/10 4:29 PM, Kevin Smith wrote:
> 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).

Hmm. If the sender (1) has verified that the recipient (full JID)
supports receipts and (2) requests a receipt, then the lack of a receipt
within some configurable timeout might indicate that the message was
lost along the way, thus legitimately leading the sender to resend.
Isn't that part of the point here? Why request receipts if you're never
going to behave any differently whether or not you receive a receipt?

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

I was thinking about this some more and I don't know if any conformance
language is needed here ("might" or "could" or "can if desired" is
probably fine instead of "MAY" or "SHOULD"). It's up to the sender
whether it wants receipts and not really a matter for the spec. However,
I'd be fine with MAY here. I do think it's worthwhile to differentiate
between the bare JID case and the full JID + discovery case.

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

Good point.

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

See above. I think "MUST NOT" is not right and was never the intent of
this spec.

>> within some configurable
>> timeout period (however, resend logic is out of scope for this
>> specification).
> 
> Then that bit can be scratched.

I disagree.

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

We're getting there. :)

Peter

-- 
Peter Saint-Andre
https://stpeter.im/



-------------- 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/5fa79310/attachment-0001.bin>


More information about the Standards mailing list