[Standards] MIX - an approach to JIDs that avoids the four into three problem
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.
More information about the Standards