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 <[email protected]> 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 >
