Hi Kevin, Thanks for your comments.
On 24 February 2017 at 10:25, Kevin Smith <[email protected]> wrote: > Hi Michal, > > On 24 Feb 2017, at 08:31, Michal Piotrowski <michal.piotrowski@erlang- > solutions.com> wrote: > > XEP-0386: Bind 2.0 spec says: > > > > > Clear the offline messages for this user, if any, without sending them > (as they will be provided by MAM). > > > > XEP-0160: Best Practices for Handling Offline Messages says: > > > > > When the recipient next sends non-negative available presence to the > server, the server delivers the message to the resource that has sent that > presence. > > > > Also the "non-negative" available presence is to my understanding a > initial presence sent by the client after bind. Should we assume that doing > Bind 2.0 client already has a resource with "non-negative" available > presence? Or how do you imagine interoperability of Bind 2.0 and Best > Practices for Handling Offline Messages? > > > > I just would like to be clear about a following scenario: > > > > 1. Client A does Bind 2.0 > > 2. The server clears offline messages for this client A and delivers > unread as described in Bind 2.0 > > Offline message stores are per-account, rather than per-client, so it > clears the offline messages for the account, but yes. > > > 3. Client B sends messages to client A > > 4. Client A sends its initial presence. To my understanding only after > this point the server can deliver messages to the client's resource. > > Depending whether they’re full-JID or bare-JID messages, but yes. > > Maybe initial presence should also be wrapped up inside bind2? > This could be handy. On the other hand how should this interoperate with RFC 6121 4.2.1. In this section it's "recommended" that the client first get's roster from the server and after that sends the initial presence. I'm just trying to figure out what's the best way for Bind 2.0 to cooperate with other pieces we already have in XMPP. > > > I'd gladly hear what I missed. > > Nothing, I think. > > /K > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > [1] https://tools.ietf.org/html/rfc6121#section-4.2.1
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
