<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 2 June 2018 at 09:25, Steve Kille <span dir="ltr"><<a href="mailto:steve.kille@isode.com" target="_blank">steve.kille@isode.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">We've been talking about a number of variants to deal with the problem of<br>
encoding four pieces of information in a JID structure that only allows<br>
encoding of three.<br>
<br>
Here is an approach to avoid the problem.<br>
<br>
These JIDs are mostly (exceptions discussed below) used in the "from" of<br>
stanzas coming from a MIX channel.<br>
<br>
There is no issue with messages from MIX, as there is no reason to encode<br>
the sender's resource.   So variant 2 gives a clean approach with  from JIDs<br>
of the form  channel@domain/stable-<wbr>participant-id  .   The resource is used<br>
to identify the sender.  A bit like MUC, but using a stable ID instead of<br>
the nick.   Information needed to display the sender is carried as elements<br>
in the message, so no lookup is needed to correctly display the sender.<br>
<br>
We can do the same with presence.   Just have presence come from<br>
channel@domain/stable-<wbr>participant-id.   This feels clean.   Other<br>
information is held as attributes in the presence.   For JID Visible, this<br>
includes the full JID of the sender.   For JID Hidden, it includes the<br>
anonymized resource.   This feels clean.<br></blockquote><div><br></div><div>So a presence unavailable from a full jid means that full jid might still be available?</div><div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
The only problem to address is when in a JID Hidden channel, the recipient<br>
wants to address a specific client (PM or vCard lookup).  A solution here is<br>
to is to use the channel@domain/stable-<wbr>participant-id addressing to the<br>
channel, and include the anoymized resource as an extension attribute to the<br>
message/IQ, which the MIX channel can use in conjunction with the JID to<br>
look up the correct full JID.<br></blockquote><div><br></div><div>The problem here is extending an <iq/> universally.</div><div><br></div><div>When we designed the <iq/> stanza, we required that it had, for requests, one and only one child element.</div><div><br></div><div>Moreover, in general terms, we frown on namespaced attributes, because of the complexities of handling these in a consistent manner throughout the network.</div><div><br></div><div>So unless you have a specific suggestion I've missed here, I think this might be a non-starter.</div><div><br></div><div>(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).</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Thoughts?<br>
<br>
<br>
Steve<br>
<br>
<br>
<br>
<br>
______________________________<wbr>_________________<br>
Standards mailing list<br>
Info: <a href="https://mail.jabber.org/mailman/listinfo/standards" rel="noreferrer" target="_blank">https://mail.jabber.org/<wbr>mailman/listinfo/standards</a><br>
Unsubscribe: <a href="mailto:Standards-unsubscribe@xmpp.org">Standards-unsubscribe@xmpp.org</a><br>
______________________________<wbr>_________________<br>
</blockquote></div><br></div></div>