[Standards] Comments on Chat Markers

Spencer MacDonald spencer.macdonald.other at gmail.com
Sat Jul 6 19:56:05 UTC 2013


Before I send in my update with the above changes, I am think about adding
a requirement that all messages that can be marked, should have an
"allowed" child element.

 <allowed xmlns='urn:xmpp:chat-markers:0'>

This means that messages containing only Chat States, Delivery Receipts etc
are not included in Chat Markers and this will network traffic for
redundant Chat Markers.

Does anyone have an opinion on this?


On Thu, Jul 4, 2013 at 1:39 PM, Spencer MacDonald <
spencer.macdonald.other at gmail.com> wrote:

> Hi Kevin,
>
> 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.
>
> Regards
>
> Spencer
>
>
> 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
>> concerns.
>>
>> 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.
>>
>> /K
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20130706/af3c7173/attachment.html>


More information about the Standards mailing list