On Thu, Jun 17, 2010 at 2:29 PM, Konstantin Kozlov <yag...@yandex.ru> wrote: >> On Wed, Jun 16, 2010 at 8:10 PM, Konstantin Kozlov <yag...@yandex.ru> >> wrote: >>> Yes. Let's sort out what means "received", "displayed" and "read" to >>> decide which of them are needed and which are not. >> Yes. >> So: >> What's the use case for needing to know when the user's client has >> received the message? >> > > If sender wants to be sure, that client on the other side received and > processed the message. So, the sender is sure that once the user on the > other side will pay attention to its client application, he'll be able to > read the message. > If delivery of all the previous messages were confirmed by the <received /> > reply and THIS one was not, the sender may assume, that the message was lost > somehow and may try to resend it (if he wants).
OK - can you tell me how this need is better met by this behaviour than by XEP-0198? 198 gives much firmer guarantees on delivery than this method does. As we discussed at length in the last review of 184, receipts here are very vague. If you receive a receipt then you know that the user has had the message displayed to them (or received by the client, depending how you interpret the text). The converse is not true - if you don't receive a receipt you can't derive anything from this except that you haven't had the receipt yet. Note that we could write a XEP that has more reliable end to end acks if that would give us more reliability than just implementing 198 (The text in 184 hints at the possibility). >> What's the use case for needing to know when the user has been shown >> the message? > I don't know. For me knowing that message was displayed on the other side > is absolutely useless. Ok. Does anyone disagree and want this information? >> What's the use case for when the user must have read the message? > For me, knowing, that user on the other side read the message is very > useful. 'cause if I got <received /> confirmation from the other side, but > getting no <read /> confirmation from the other side for a long time, I'll > assume that user didn't noticed notification of my message arrival. So, I'll > try to attract his attention, for example, using XEP-0224 (Attention). > <http://xmpp.org/extensions/xep-0224.html> I can see two cases here 1) The user doesn't need a reply urgently 2) The user needs a reply urgently. As I see things, if (1) is true, there's no need to go sending 224 pokes to get a response, and in (2) you'd send a 224 poke (if you were so inclined) irrespective of whether you get a read receipt or not if you didn't have a reply. Is that reasonable? /K
