[Standards] Comments on Chat Markers
spencer.macdonald.other at gmail.com
Thu Jul 4 12:39:48 UTC 2013
Thanks for the feedback,
As I mentioned on another thread, I see no reason why we shouldn't add a
'displayed'/'read' element to XEP-0184, in addition to Chat Markers.
I think as you suggested that it would be wise to point out that Chats
Markers are only heuristics, not having to ack every message with a receipt
is one of the major benefits of using Chat Markers so I wouldn't want to go
down this road.
On Thu, Jul 4, 2013 at 11:45 AM, Kevin Smith <kevin at kismith.co.uk> wrote:
> After reviewing the Chat Markers proposal for Council, I have two main
> 1) It's not clear to me that by adding a <read/> equivalent to 184,
> using MAM and chat states that we wouldn't have a simpler solution
> with more re-use of existing paradigms. This comment isn't blocking.
> 2) It seems to me that this proposal is providing users with the
> highest assurance of delivery ("This message has been read and
> acknowledged by the user"), when it's possible that some of the
> acknowledged messages were never delivered. This seems serious to me
> in situations like:
> <User A> Something terrible has happened, please send help.
> [S2S blips, message gets lost]
> <User A> There's high winds here.
> [S2S is back, message gets delivered]
> User B now acknowledges the 'high winds' message as read.
> Because of the 'up to this point' nature of the proposal, User A has
> now had it acknowledged that User B has read the message about needing
> to send assistance.
> There seem to be multiple ways to address this - one is to use an
> approach more like 184, with per-message acks. Another is to say that
> this proposal requires reliable transport, and that every message
> needs to have 184 as well as chat markers in order for the markers to
> be believed. Another is to put a banner across the top of the chat
> markers spec saying that the acks it provides are only heuristic and
> can't be used to assure users of messages being delivered or read.
> I think it's worth addressing this somehow, using one of the above
> suggestions or some other, before this is published as implementation
> as-is could conceivably lead to fatal misunderstandings in some of the
> situations XMPP gets used.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards