> 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. 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).

/K
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________

Reply via email to