[Standards] MIX - an approach to JIDs that avoids the four into three problem
kevin.smith at isode.com
Sat Jun 2 11:43:34 UTC 2018
On 2 Jun 2018, at 10:22, Steve Kille <steve.kille at isode.com> wrote:
>>> 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).
> 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?
I think it’s a hell of a compromise if we’re choosing not to allow iqs - it means no caps/disco, no ability to make calls, transfer files, …
Maybe that’s what people would be happy with, but it means JID-anom is no longer just about not revealing your true JID, but about preventing many types of communication.
More information about the Standards