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 <[email protected]> >> 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 <[email protected]> or a full JID <[email protected]/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. ***
smime.p7s
Description: S/MIME Cryptographic Signature
