Re: [Standards] XEP-0333: meaning of 'acknowledged'

[Konstantin Kozlov]

I think, user have to explicitely acknowledge. So, it should be something like 
"Ack" button for this.
Acknowledge by other user action is not a good idea, I think.

21 мая 2020 г. 19:45:00 GMT+05:00, Matthew Wild  пишет:
>Hi folks,
>
>XEP-0333 defines the state:
>
>> acknowledged -- the message has been acknowledged by some user
>interaction e.g. pressing an acknowledgement button.
>
>If a user scrolls down to the bottom of a chat log, we know they are
>present and looking at the screen. This is user interaction. Should a
>client send ?
>
>Regards,
>Matthew

-- 
Простите за краткость, создано в AirMail.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0393 and XEP-0394 naming

[Konstantin Kozlov]

Hello!8 марта 2018 г. 21:26 пользователь VanitasVitae  написал:Also if we'd do that, we'd have "Message Markup" and "Message Markdown"...Yeah, but it will be really funny. Just like "more" and "less" viewers Linux! :-)With my best regardsKonstantin___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] 2017-11-08 XSF Council Minutes

[Konstantin Kozlov]

It's too bad you didn't use your veto against that awful proto.It don't even worth to waste XEP number for things like this one.___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] LAST CALL: XEP-0313 (Message Archive Management)

[Konstantin Kozlov]

Hello!17 нояб. 2017 г. 20:22 пользователь Matthew Wild  написал:On 15 November 2017 at 17:32, Kozlov Konstantin  wrote:

> That's nice!

> This XEP is still too raw.



Just out of curiosity, care to share your thoughts on what needs polish?



I don't disagree with the council's decision, but I didn't see any

prior feedback from you in this thread yet and I'm keen to document

anything that needs to be worked on for the next revision.
The main problem I see so far is inability to determine for which dates message archive is available without reading the whole archive.Author of Vacuum IM (which is an upstream of my client) tried to implement XEP-0313 instead of XEP-0136, but gave up because of lack of such functionality.Vacuum IM has very convenient interface to manage history and he don't want to break it.With my best regards,Konstantin

___
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

Re: [Standards] XEP-0167: How to?

[Konstantin Kozlov]

Hello!

20 июня 2016 г. 0:02 пользователь Philipp Hancke  
написал:
>
> Am 19.06.2016 um 09:12 schrieb Kozlov Konstantin: 
> > Hello! 
> >
>
> typically that is done by looking at the payload type of the rtp 
> packets. You could have multiple 'codecs' like rtx after all 
And how can I tell FFMpeg (which I use to play an RTP steam), to look at RTP 
packets to find payload type? RFC 4566 (5.14), if more than one payload type 
numbers specified in m= line, first one SHOULD be used as the default format 
for the session. So, if I specify more than one payload type, and the first 
payload type number I listed in m= line is not the payload type being used to 
stream, FFMpeg library just hangs on avformat_find_stream_info() call, waiting 
for a packet with appropriate payload type.

With my best regards,
 Konstantin
___
Standards mailing list
Info: http://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
___

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

[Konstantin Kozlov]

Kevin Smith wrote:

On Thu, Jun 17, 2010 at 2:29 PM, Konstantin Kozlov yag...@yandex.ru wrote:
  

  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?
  

   No, I don't think so.
   As it stated in XEP-0224, it should be used to attract user's 
attention, if you suppose he's not focused on his client. Using that 
buzz just to force other side answer you is really rude. If I see that 
other side read my message, but do not answer, I'll wait a little, than 
ask him, why he didn't reply.
   One of my friends often sends buzz just after he sends a message. 
These times I'm almost about to kill him!

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

[Konstantin Kozlov]

Waqas Hussain пишет:

On Fri, Jun 18, 2010 at 5:00 PM, Konstantin Kozlov yag...@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?

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

[Konstantin Kozlov]

Yann Leboulanger пишет:

On 06/18/2010 08:20 PM, Konstantin Kozlov wrote:

Waqas Hussain пишет:

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.


Why that? active/ means chat windows is active, not that a popup 
appreaed.



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.


What's the difference bwtween receiving a read/ amd receiving a 
active/ stanza?
   'Cause in some implementations, pop-up may contain whole message. 
And clicking? for example, Ok in such pop-up will dismiss it and 
acknowledge that message is read by the user. So, the other side will 
receive read / without receiving active /.


   Another example: we receive active/ notification. Then we receive 
composing/ notification. The we decide to send a message. The message 
is sent and we receive received / notification. Now, how do you think, 
the user on the other side read your message, or not?

   In fact? it's implementation dependent:
   1. In Psi, if user is composing a message, it's chat window is 
active and he will see your message just when it arrived.
   2. In Bombus, if user composing a message, he cannot see message 
list, 'cause current screen is message edit textbox. So, he'll see your 
message after he'll send his one or will suspend editing. And if 
something's diverted his attention while he composing message, he won't 
read your message 'till he remember about it.
   So, you have to analyze message receipts, chat state notifications, 
client version to guess if user on the other side read your message. Ind 
is some cases even that is not enough. Need examples?

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

[Konstantin Kozlov]

Waqas Hussain wrote:

On Fri, Jun 18, 2010 at 11:20 PM, Konstantin Kozlov yag...@yandex.ru wrote:
  

  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.



My mistake. I assumed you were agreeing with Kev.

   No, do not. I agree with the author.

 You were suggesting
a new read/ element be added to message receipts?
  

   Yes.

As Yann Leboulanger noted, active/ does what you think read/
should do. See http://xmpp.org/extensions/xep-0085.html#definitions
  
   Ok. I've already replied to Yann Leboulanger, trying to show that it 
does not.

If you can't imagine that, then you clearly aren't trying

  Believe me, I really did.


You mustn't get a lot of messages then. I can get swamped by messages
at times. Most of them don't require/expect a response. Also, I'm not
always paying attention to the screen, or to the IM client. When you
have multiple items requiring focus, some get higher priority than
others. That's not unreasonable.

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?


So, I don't want to take action to mark those as read immediately, and
I don't want the other side to assume that I'm not reading. I am
reading them. Just don't want to alt-tab when a response doesn't need
to be written.
  
   Ok. Maybe in some situations this extension will not work as it 
should. But in most cases it will.

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

[Konstantin Kozlov]

Kevin Smith 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).

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.

What's the use case for when the user must have read the message?
(and noting as above that the last two are probably as close to
synonymous as you'll get in a reasonable UI).
  
   No. If we have reasonable UI, the last one is far from synonymous to 
the previous one. The last one means, that UI somehow assumed that user 
read the message, so the message changed its state from new to read 
one. On the most clients message don't marked as read automatically 
when it's displayed.
   For example, in Psi the message becomes read when it's displayed 
in the chat window and the chat window is active (has input focus).
   In Bombus the message becomes read when appropriate chat is 
current screen and user confirms the message by moving joystick or 
clicking button or tapping the touchscreen. Each movement/click/tap 
marks only one message as read!
   In the application I'm developing right now, the message could be 
displayed either as a pop-up balloon or as a record in the message list 
of a chat screen. So, there are 2 different ways to mark the message as 
read. By clicking Ok button on the screen displaying the balloon 
with a message, or by highlighting it with a cursor in the message list!
   Anyway, reasonable UI marks message as read, when it has a reason 
to assume that user payed attention to 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



Then we can start to work out what needs to be included.
  

   Ok. Let's start.

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

[Konstantin Kozlov]

Kevin Smith wrote:

On Wed, Jun 16, 2010 at 7:43 PM, Kozlov Konstantin yag...@yandex.ru wrote:
  

On 06/16/2010 08:27 PM, Kevin Smith wrote:

The log, attached to the first message clearly says that even author of XEP-0184 do not agree with you, Kevin. So, why do you argue?



Well, because the way that the XEP is written reads quite clearly (to
me) that the message has to have been presented to the user, and given
that presented means displayed.
  

   Yes, but displayed doesn't mean that user read the message.

This suggests we need to sort out the wording to be unambiguous one
way or the other, and hopefully in such a way that Council agree with
the author on what it means the next time they vote :)
  
   Yes. Let's sort out what means received, displayed and read to 
decide which of them are needed and which are not.