[Standards] MIX - an approach to JIDs that avoids the four into three problem

Florian Schmaus 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.

- Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: OpenPGP digital signature
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180602/3f9b2cba/attachment.sig>

More information about the Standards mailing list