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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
