Thanks. > On 17 Jan 2017, at 20:30, Michal Piotrowski > <[email protected]> wrote: > > Hi, > > Thanks for the protoXEP, this is step in a good direction! The part which I > find the most important is the information about unread messages. Here are my > questions regarding this: > 1. How messages should be marked as read? Is this subject of another XEP or > maybe XEP-0333: Chat Markers could be used here?
We (probably I) should write another XEP covering this - I left a note in the Bind2 spec that this needs doing. I don’t think 333 is the right way to signal this stuff to the server, but I think the protocol for doing it is straightforward. > 2. What in a situation when the client have many contacts with unread > messages? Should the response indicate that there maybe more unread > conversations? How many is many? I don’t see a problem with this scaling to any human IM cases that I can think of. Do you have anything in mind? > > Note: this gets rid of manual resource binding altogether. For discussion > > on standards@ > > This maybe tricky. On one hand I think it'd be better if only the server > could assign resource, on the other hand I worked with some installations > (closed ones) where the resource where well though and contained some > informations about the client like app version or platform. This was later > used by some other parts of the entire system. It may be tricky, yes. I thought it best to raise the issue so we can discuss it, rather than just assuming we have to keep the legacy stuff. If we end up with reasons we need to keep client-requested resources, at least we’ll have concrete understanding why that is :) > > Note: also enable acks? discuss on standards@ > > Does acks mean stream management? If so then I think it's worth enabling them > by default for clients using bind 2.0 Yes, the acks from 198. /K > > > > > Best regards > Michal Piotrowski > [email protected] > > On 17 January 2017 at 16:23, XMPP Extensions Editor <[email protected]> wrote: > The XMPP Extensions Editor has received a proposal for a new XEP. > > Title: Bind 2.0 > > Abstract: This specification provides a single-request replacement for > several activities an XMPP client needs to do at startup. > > URL: http://xmpp.org/extensions/inbox/bind2.0.html > > The council will decide in the next two weeks whether to accept this proposal > as an official XEP. > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
