On 20.02.2017 14:12, Kevin Smith wrote: > >> On 20 Feb 2017, at 12:42, Florian Schmaus <f...@geekplace.eu> wrote: >> >> On 20.02.2017 12:54, Kevin Smith wrote: >>> Hi Flow, >>> >>> On 20 Feb 2017, at 11:28, Florian Schmaus <f...@geekplace.eu> wrote: >>>> >>>> On 20.02.2017 10:36, Georg Lukas wrote: >>>>> * Jonas Wielicki <jo...@wielicki.name> [2017-02-20 10:20]: >>>>>> I feel that using BIND2 resources---albeit this is likely to become the >>>>>> new >>>>>> standard---harms readability a lot. However, I can also see that using >>>>>> examples which do not fit the current standards lead to developers >>>>>> implementing the wrong things, such as clients which encourage the use >>>>>> of >>>>>> descriptive and user-chosen resources. >>>>> >>>>> I think that we need readable examples in the XEPs over anything else. >>>>> My suggestion would be to use human-readable, short resource >>>>> identifiers, both in the client case and in the auto-generated proxy >>>>> case. It is possible to convey the same information in another, indirect >>>>> way, that does not harm understanding: >>>>> >>>>> For example: >>>>> >>>>> The full user JID "alice@xmpp.example/client1-uuid" is mapped to the >>>>> proxy JID "channel+alice-uuid@mix/uuid-alice-A" >>>> >>>> Please let us have the client provided part first and *then* the UUID. I >>>> believe this would increase the readability a lot. For example >>> >>> The client provided part *is* a UUID. The client part needs to be >>> unpredictable (although consistent). >>> >>> The server part can be whatever, there’s no need for that to be randomised. >> >> Now I'm confused. I thought that we want the client to provide whatever >> he wants, and have the server add a postfix to the client provided part >> separated by '/'. >> >> For example a client performs "bind2 with 'agent-blue'" and the server >> assigns a resource like 'agent-blue/12204e53-f761-4c1d-89c9-8a9045334c20'. >> >> Wouldn't that be the best of both worlds? The server can still encode >> routing semantics, together with some random data to make it >> unpredictable. While clients can enforce the prefix of the Resourcepart >> for the reasons we discussed (e.g. debugging). > > Clients are going to need to use a consistent approach to globally unique > naming.
I don't follow. Could you rephrase that? Is that saying that clients must only provide UUIDs (or similar) as the resource's clientpart when using Bind2? Then why allow them to provide a part at all? > If they’re not unique then you’ll get collisions and all the benefits are > lost. The server is still able to avoid collisions, after all, he is the entity which ultimately decides what the resource for a client should be. The only guarantee will be that the client provided part will start the resourcepart. > (And if they’re not consistent then they’ll be fingerprintable, which seems > like a sensible thing to avoid while we’ve got the chance). Fingerprintable as in someone can tell the client from looking at the resourcepart? Yes that should be avoided in general. But I still want the client to be allowed to provide whatever he chooses as prefix for the resourcepart. As it makes debugging XMPP in cases where you control the client, e.g. integration tests, a lot easier. - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
