Thanks again. On 11 Oct 2017, at 18:14, Georg Lukas <ge...@op-co.de> wrote: > 1. Resource identifiers in the JID > > Those are unique, so a server must either kill the old session or refuse > the new session on conflict. IMO clients that create a randomized > resource string on account setup, or keep the one initially assigned by > the server, plus servers that kill the old session on a resource > conflict provide a very sane and reasonable setup that works today. > > Pro: a client comes back with the same "public" identifier.
Well, it might, but the server is allowed to change it, so you can’t rely on it. > Contra: not cloud-scale, because it requires a global lock when a client > reconnects. However, a global lookup table is needed anyway to enumerate > all resource of a client for presence / bare-JID routing. It’s much easier to keep a global lookup table if you don’t have to deal with conflicts because the identifiers are node-specific - that’s where the gain in not needing the (effective) lock comes in here. > 3. Double-Resourcepart proposed in the context of Bind 2 > > Something like `<client-unique-id>/<server-generated-id>` as a > resourcepart, where a stable client ID is combined with some > cluster-node identifier from the server > <https://mail.jabber.org/pipermail/standards/2017-February/032089.html> > > Pro: cloud-scale. > > Contra: visible to people who are subscribed to you. > > Contra: client identifier changes when reconnecting to a different > cluster node. This is true, but does it matter? You can always look at the two resources and see if they’re the same client, which solves the often-works-but-can’t-be-relied-upon behaviour people currently want from requested resources, while also satisfying the need to have servers able to munge them. > It might be useful to have a hidden or visible persistent client > identity stored on the server and associated when authenticating / > binding. Maybe even one the user can see and remove from the server's > web interface ;) This is true. I think split/resources solves it, but it’s desirable whatever solution. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
