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

Kevin Smith kevin.smith at isode.com
Sat Jun 2 11:40:08 UTC 2018


On 2 Jun 2018, at 10:10, Dave Cridland <dave at cridland.net> wrote:
>> On 2 June 2018 at 09:25, Steve Kille <steve.kille at isode.com> 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  .   The resource is used
>> to identify the sender.  A bit like MUC, but using a stable ID instead of
>> the nick.   Information needed to display the sender is carried as elements
>> in the message, so no lookup is needed to correctly display the sender.
>> 
>> We can do the same with presence.   Just have presence come from
>> channel at domain/stable-participant-id.   This feels clean.   Other
>> information is held as attributes in the presence.   For JID Visible, this
>> includes the full JID of the sender.   For JID Hidden, it includes the
>> anonymized resource.   This feels clean.
> 
> So a presence unavailable from a full jid means that full jid might still be available?
> 
> Don't get me wrong, here - we *have* to break some 1:1 semantics for any groupchat protocol, I think. But also I think it's important we understand which semantics we're breaking.

Yes - and I don’t think this is one it would be nice to break if we can avoid it.

>> 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.
> 
> The problem here is extending an <iq/> universally.
> 
> When we designed the <iq/> stanza, we required that it had, for requests, one and only one child element.
> 
> Moreover, in general terms, we frown on namespaced attributes, because of the complexities of handling these in a consistent manner throughout the network.
> 
> So unless you have a specific suggestion I've missed here, I think this might be a non-starter.

I think so.

> (That said, if we *could* drop in extension elements into an <iq/>, that would be amazingly useful - but at least one server I'm aware of explicitly checks and rejects get/set iqs with multiple child elements).

I’m assuming they all do. M-Link certainly does.

/K


More information about the Standards mailing list