On 28 May 2013 21:44, XMPP Extensions Editor <edi...@xmpp.org> wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Chat Markers > > Abstract: This specification describes a solution of marking the last > received, read and acknowledged message in a chat. > > URL: http://xmpp.org/extensions/inbox/chat-markers.html > > The XMPP Council will decide in the next two weeks whether to accept this > proposal as an official XEP.
A couple of council members (including myself) at the meeting yesterday decided not to accept this proposal as it stands. The main issue for me is that it is unclear about how the protocol would work in a federated environment. It needs to be clearly specified which stanzas are sent to and handled by which server, for example. I'm not sure if the XEP is covering this and simply needs to be more clear, or if it's neglecting to deal with s2s entirely. A more general issue is whether this XEP (or rather the specific protocol it defines) s necessary at all. I'm not saying it definitely isn't, but need a little more persuasion. For example it seems that the primary issue it is working around is that XEP-0136 and XEP-0313 might not save messages with no body. Might it not be easier to solve this problem instead? For XEP-0136, it appears to be configurable already in the archiving preferences (surprise surprise!). For XEP-0313, I'm open to discussion about what it recommends. XEP-0313 intentionally remains silent on most policy decisions like that. However it seemed sensible at the time that nobody would want to archive messages without a body, which on the network today are primarily chat states and notifications of various sorts. The XEP is still experimental, perhaps we can come up with better rules? I don't know, that's a discussion for another thread. Forgetting archiving completely for the moment, offline messages might do enough already, no? XEP-0160 doesn't actually have any recommendations about what to store or what not to store. It seems that servers are expected to identify things like chat states already (XEP-0085 says that servers "SHOULD NOT store them offline"). This doesn't seem like a good model, but it's what we currently have. If we can disentangle this mess about how servers treat different kinds of messages, would this be a viable alternative to the current chat markers proposal? Unlike the current proposal, it's possible that no server modifications would be necessary, which would greatly speed adoption of such a protocol that does what you need. Regards, Matthew
