Enable/Disable vs Subscribe/Unsubscribe I did originally have the element named "enable" instead of "subscribe", but I felt it read like you were enabling/disabling chat markers entirely rather than them just enabling/disabling them being automatically pushed to you.
As mentioned in another thread, an alternative approach would be to automatically send your chat markers if you advertise support which negates this step. IQ vs Message A message based approaches was considered as both chat states and delivery receipts use them, but it had the following disadvantages: - You lose the ability for the server to insert timestamps. - As mentioned current message archiving solutions don't currently store messages with no body. - The sender has no way of knowing if an offline entity supports chat markers, so what does the sender do in this situation? Regards Spencer On Wed, May 29, 2013 at 6:53 AM, Philipp Hancke <[email protected]>wrote: > Am 28.05.2013 22:44, schrieb XMPP Extensions Editor: > > 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<http://xmpp.org/extensions/inbox/chat-markers.html> >> > > quick glance: > > section 2: > The term "active chat" refers to a chat that a user is currently active in. > -- doesn't 0085 have a definition of that? > > section 4: > read -- the message the user has viewed it in a active chat. > s/the message// > > displayed -- the message has been displayed to the user in an > active chat > would be easier to define than "the user has viewed it" > > > section 6.1: > can this be more aligned with what we have in carbons? E.g. > <iq xmlns='jabber:client' > type='set' > id='enable1'> > <enable xmlns='urn:xmpp:chat-markers:**tmp'/> > </iq> > > > Design-wise I'd prefer <message/> to <iq/>. But I think the rule not to > store bodyless messages is wrong and therefore ignore that. The offline > use-case is important however. > > <message/> in combination with carbons might fulfill the multi-client > usecase better. > >
