[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?

 

 

 

Steve

 

 

 

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