On 3/13/10 11:04 AM, Kevin Smith wrote: > 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.
Except that version 1.0 of XEP-0184 says the following: *** 7. Implementation Notes Although a sender MAY attempt to resend a message if it knows that the recipient supports message receipts and it does not receive a reply within some configurable timeout period, resend logic is out of scope for this specification. *** It seems you are proposing to remove that paragraph or anything like it. I agree that the current text punts on retry logic. I propose that we specify it more carefully, not pull it out altogether. > 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). Email clients don't have disco and caps for online resources. > 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. Edge case. So we modify the text to read: *** If the sender determines that the recipient's client supports message receipts then it MAY request a receipt when sending a message of type "chat", "headline", or "normal" to that full JID. If the sender has requested a receipt, it MAY depend on receiving a receipt and MAY resend the message if it does not receive a receipt within some configurable timeout period ___and if it does not in the meantime receive an unavailable presence notification from the full JID to which it sent the message___. *** The stuff about "configurable timeout period" is a bit of a dodge, too, but we might be able to live with that. > 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. I don't think that a negotiation protocol (XEP-0155 or XEP-0020 or a new Jingle "chat session" application type) is needed here, just a set of good rules for resending. >>> 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"). Sure. >>> 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). See above. ;-) > 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. And I'm hoping that you change yours. :P >>>> 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. Asymptotically approaching perfection, no doubt. Perhaps you and I need to talk about this using a technology that enables near-real-time communication. If only someone had invented such a thing... Peter -- Peter Saint-Andre https://stpeter.im/
smime.p7s
Description: S/MIME Cryptographic Signature
