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 <[email protected]> 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 <[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 "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
