On Sat, Mar 13, 2010 at 4:47 AM, Peter Saint-Andre <[email protected]> wrote: > 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?
Well, that's the point I've always made, pretty much. XEP-0184 provides something akin to email read receipts - email clients don't go resending emails if they haven't received a receipt by the next day, because the user may just not have fired up their email client yet, or they could be one of the people who doesn't send read receipts (there're a number of them about). What my email client is able to do is to show some notification that "Peter has confirmed he's read this message" when I send you a message with a request in it, and that's exactly what a XEP-0184 client is able to do, 184 serves this purpose very well, but if you happen to go offline, or don't check your messages at the weekend, or (goodness!) take a holiday I'm firmly off the belief that my client shouldn't be spamming you with the message more than once. Now, with that said, if end to end delivery receipts for the sake of delivery confirmation is a requirement here, I think the XEP can be made to work - I think what we'd need to do is (only for full-jid to full-jid sessions) negotiate an agreement that both clients will be sending a receipt for every message, and if it's not received within X long to retransmit it. This doesn't have any of the issues I mentioned before of unwanted retransmissions, because it's all consensual, and was defined in version 1.0 of the spec. >> 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. > > 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. I'm happy not to use conformance language for this, although I equally don't see much reason not to use MAY (it is "Truly optional"). >> 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. See above :) (snap). I note that the 1.0 text is explicit that <received/> is only sent if the receiver wishes to inform the sending entity that the message has been received, and this hasn't been removed from 1.1rc3. I think it's harmful to say to receivers "Yeah, you don't need to generate the receipt if you don't want to", while telling the sender "It's fine to keep sending until you get a receipt". >>> within some configurable >>> timeout period (however, resend logic is out of scope for this >>> specification). >> Then that bit can be scratched. > I disagree. I know, I'm hoping to change your mind. >>> 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. :) I think so. /K
