[Standards] Resourceparts with Bind2
flo at geekplace.eu
Mon Feb 20 13:41:09 UTC 2017
On 20.02.2017 14:12, Kevin Smith wrote:
>> On 20 Feb 2017, at 12:42, Florian Schmaus <flo at geekplace.eu> wrote:
>> On 20.02.2017 12:54, Kevin Smith wrote:
>>> Hi Flow,
>>> On 20 Feb 2017, at 11:28, Florian Schmaus <flo at geekplace.eu> wrote:
>>>> On 20.02.2017 10:36, Georg Lukas wrote:
>>>>> * Jonas Wielicki <jonas at 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 at xmpp.example/client1-uuid" is mapped to the
>>>>> proxy JID "channel+alice-uuid at 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
> (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.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 610 bytes
Desc: OpenPGP digital signature
More information about the Standards