On 2 Jun 2018, at 10:22, Steve Kille <steve.ki...@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@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. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
