[Standards] XEP-0184: <received/> vs. <displayed/> vs. <read/>

Konstantin Kozlov yagiza at yandex.ru
Fri Jun 18 18:20:59 UTC 2010

Waqas Hussain пишет:
> On Fri, Jun 18, 2010 at 5:00 PM, Konstantin Kozlov <yagiza at yandex.ru> wrote:
>>   Well. According to my experience, based on knowledge of my behavior and
>> behavior  of my friends, the fact that my message is not "new" anymore on
>> the other side is enough to assume that user on the other side read it.
> See XEP-0085: Chat State Notifications. That nicely solves the problem
> of determining if the other side is paying attention to the
> conversation.
    No. We don't know how messages represented on the other side. It 
could be chat windows, pop-ups or whatever author of the application can 
imagine. So, in some implementations some (or all) chat state 
notifications are meaningless or has limited usability.
    Also, analyzing chat state of the other side trying to guess if the 
user paid attention to your message is much less convenient than just 
receive <read /> notification.
>>   As for me, running chat application is for chatting. For reading and
>> writing messages. I can't image a guy who just ignores messages from
>> contacts in his contact list, just confirming without even reading them. At
> If you can't imagine that, then you clearly aren't trying.
    Believe me, I really did.
>> least neither me nor any of my friends behave that way. What is he running
>> his IM application for? If he don't want to read message from the specific
>> contact, he can just put it into hist ignore list, and he will never receive
>> any confirmation message. But, once again, confirming reading of the message
>> without reading it actually sounds strange for me.
> Not all conversations are equal. Much of it is background chatter, or
> messages which don't actually require a response. It's quite
> convenient following such conversations in a background window, or
> through popups (toasts).
    So, what?
>  I absolutely wouldn't want to have to
> manually indicate my having read every message I receive.
>>   If there are some people, who doing so, that's the problem of those
>> people. Why other people should suffer because of them? Let's give to other
>> people such ability, 'cause in the most cases it will be really useful.
> XEP-0184: Message Receipts solves a very specific problem for me: It
> lets me know my message got through, and wasn't swallowed by a network
> issue or server crash. All clients implementing the XEP do let me be
> sure of this. Changing this existing behavior would awkward, error
> prone, and of limited utility: i.e., very unwelcome.
> A lot of people are on wireless networks, or have otherwise turbulent
> connections, or have servers which crash. This isn't a rare problem at
> all. Your useful ability can be achieved through other means
> (XEP-0085: Chat State Notifications). Don't force the rest of us to
> suffer please.
    Your response sounds like either you didn't read my previous 
messages at all, or just didn't understood the idea.
    The idea is:
1. You don't "have to manually indicate your having read every message 
you receive". As I said before, most of the clients already marking just 
arrived messages as "new", to tell user, that he has unread messages. 
Then somehow they decide that user read the message, the message marked 
as "read". That (already existing) mechanism is supposed to be used to 
send that <read /> confirmation. So, you don't have to do manually. In 
fact, as a recipient of the message, you won't notice any changes at all!

2. Adding <read /> element to the XEP won't change existing behavior at 
all. If either of clients do not support <read /> element, it won't 
notice anything.  It will just process <received /> notification and 
following <read /> notification either will not be sent or will be 
ignored. If both of them are supporting new XEP, then after receiving 
<received /> notification, you'll get <read /> notification just after 
message on the other side will be marked as "read".
Now, tell me, how this extension of the original behavior can break it, 
making "awkward, error prone, and of limited utility"? Or how it can 
make suffer anyone?

More information about the Standards mailing list