[Standards] Resourceparts with Bind2
flo at geekplace.eu
Mon Feb 20 12:42:36 UTC 2017
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).
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 610 bytes
Desc: OpenPGP digital signature
More information about the Standards