[Standards] MIX - an approach to JIDs that avoids the four into three problem
flo at geekplace.eu
Sat Jun 2 10:44:48 UTC 2018
On 02.06.2018 10:25, Steve Kille wrote:
> We've been talking about a number of variants to deal with the problem of
> encoding four pieces of information in a JID structure that only allows
> encoding of three.
> Here is an approach to avoid the problem.
> These JIDs are mostly (exceptions discussed below) used in the "from" of
> stanzas coming from a MIX channel.
> There is no issue with messages from MIX, as there is no reason to encode
> the sender's resource. So variant 2 gives a clean approach with from JIDs
> of the form channel at domain/stable-participant-id .
And 'stable-participant-id' being a random unique string or the MIX
nickname (xep369 § 7.1.4)?
I think I'm currently in the
- messages from channel at service/nick
- IQs to/from and presence from channel at service/nick/client-id
(where client-id is a random unique string not containing '/')
But the discussion about all those variations gets confusing quickly.
How about creating a Wiki page with lists all currently suggested
variants and its pros and cons?
> The only problem to address is when in a JID Hidden channel, the recipient
> wants to address a specific client (PM or vCard lookup). A solution here is
> to is to use the channel at domain/stable-participant-id addressing to the
> channel, and include the anoymized resource as an extension attribute to the
> message/IQ, which the MIX channel can use in conjunction with the JID to
> look up the correct full JID.
Extending IQs is possible (just not by putting the extension elements as
direct child elements to <iq/>, see for example how RSM does it), but it
feels like a bad design if we used that in this case.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 618 bytes
Desc: OpenPGP digital signature
More information about the Standards