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

Steve Kille steve.kille at isode.com
Sat Jun 2 09:22:54 UTC 2018



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

[Steve Kille]


Perhaps a better approach would be to not support vCard/IQ of clients through a JID Hidden channel.


PMs can work fine.   


Is there really much utility to support general querying of anonymized clients through a MIX channel?








-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180602/2630ea17/attachment.html>

More information about the Standards mailing list