[Standards] Resourceparts with Bind2

Kevin Smith kevin.smith at isode.com
Mon Feb 20 13:12:11 UTC 2017

> 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. If they’re not unique then you’ll get collisions and all the benefits are lost. (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).


More information about the Standards mailing list