[Standards] Bind 2.0 and Best Practices for Handling Offline Messages interoperability
michal.piotrowski at erlang-solutions.com
Fri Feb 24 12:10:11 UTC 2017
Thanks for your comments.
On 24 February 2017 at 10:25, Kevin Smith <kevin.smith at isode.com> wrote:
> Hi Michal,
> On 24 Feb 2017, at 08:31, Michal Piotrowski <michal.piotrowski at 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
> > 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.
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Standards