[Standards] Clarification on iq routing in semi-anonymous MUCs

Jonas Schäfer jonas at wielicki.name
Mon Dec 9 20:29:08 UTC 2019


On Sonntag, 6. Oktober 2019 17:15:11 CET Marvin W wrote:
> Hi,
> 
> On 06.10.19 14:46, Jonas Schäfer wrote:
> >> Currently server implementations seem to have diverting behavior in this
> >> regard: ejabberd and Prosody<0.11 route IQs to the full JID (any of them
> >> if there are multiple) except if the IQ contains a vCard query, which is
> >> send to the bare JID. Prosody 0.11+ routes PubSub IQs to the bare JID.
> >> ejabberd allows to disable IQ forwarding on a per room basis
> >> (allow_query_users config).
> > 
> > FTR, this is, as all of Multi-Session Nick, implementation-defined land.
> > We
> > should probably clean this up indeed.
> > 
> >> What is supposed to be the correct behavior? Can we clarify in
> >> XEP-0045§17.4 how to correctly route IQs in a MUC?
> > 
> > Yes please, also Multi-Session Nick in general. It is a dark field of
> > things which is mostly passed on by tribal knowledge.
> > 
> > I wonder whether it would make sense to mix both into the same add-on XEP.
> 
> I don't think that multi session nicks and iq routing are directly
> related. Routing IQs to bare vs full jid makes a huge difference even in
> single sessions.
> 
> Intuitively, if we wouldn't have multi-session nicks, I would argue that
> IQs are to be routed to the full JID, because that's the same as
> messages and there is no indication in XEP-0045 that IQs MAY be handled
> differently, although there also isn't any explicit mention that they
> SHOULD NOT.
> 
> However with multi-session nicks, IQ routing to the full JID makes less
> sense, because there are multiple of them, so it is somehow related. In
> fact in the wiki there is https://wiki.xmpp.org/web/Multi-Session_Nicks
> which has a section on IQ routing, asking IQs to be routed to one of the
> connected full JIDs
> 
> I think we should
> a) Clarify the routing of IQs in XEP-0045 or at least clarify that IQ
> routing in MUCs is intended to be undefined behavior in XEP-0045 but
> might be defined in other XEPs.
> b) Write down the rules of multi session nicks (including IQ routing) in
> a new XEP

I agree.

> One additional idea regarding IQ routing (and probably terribly
> over-engineered) would be that the occupant somehow indicates how they
> want their incoming IQs to be routed. This could even be statements like
> "route vcard requests to bare jid, route pings to full jid and
> ignore/error everything else". In multi session nick scenarios one could
> even combine these statements so that some iqs are forwarded to bare,
> some to full jid A and some to full jid B. - But if we do this, it
> probably does not belong into XEP-0045...

I’m pretty sure that we should not do this. This is, indeed, terribly over-
engineered, and at the risk of sounding like part of a huge, unlikeable herd: 
This is hopefully not going to be a problem with MIX anymore, since resources 
of members (and the bare JID itself) can be fully addressed there.

Writing down how we want things to currently happen in XEP-0045 and slapping a 
feature var on it is probably a good idea. Going full in and trying to find 
another solution to the "multiple entities behind an address" problem, 
probably not.

kind regards,
Jonas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20191209/b0f80a04/attachment.sig>


More information about the Standards mailing list