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

Dave Cridland dave at cridland.net
Sat Jun 2 09:10:51 UTC 2018


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.


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

(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).


>
> Thoughts?
>
>
> Steve
>
>
>
>
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180602/0ddeac2a/attachment-0001.html>


More information about the Standards mailing list