[Standards] Addressing for IQs in MIX-CORE

Dave Cridland dave at cridland.net
Mon Jun 4 15:06:02 UTC 2018


On 4 June 2018 at 15:43, Jonas Wielicki <jonas at wielicki.name> wrote:

> I think this is a good point, and I’ve run into this quite a few times
> when
> implementing MUC. Branching on the message type where 'groupchat' is
> somehow
> special, but then again only if it does *not* come from the bare JID, and
> if
> it *does* come from the bare JID, you may be confused (but that happens,
> in
> fact). And non-groupchat messages from the bare JID have a different
> semantics
> than non-groupchat messages from the occupant JID (I’m only talking about
> MUC
> here). This is weird, and I think if MIX does away with that, that would
> not
> be too bad.
>
>
I'm not sure that type=groupchat messages from the '45 chatroom bare jid
are different from type=groupchat messages from the '45 occupant bare jid
except in who they're from, are they? I mean, they're different because
they're from the chatroom itself, of course, but beyond that?

Well, errors, I suppose, come from the bare jid, but they're not groupchat
of course.


>
> A random side note: I found another argument against the variant where the
> client resource is encoded together with the participant id in the
> resource:
> The client resource is -- in contrast to the channel name and participant
> id
> -- not under control of the MIX service. A client resource can be very
> long
> (although it probably isn’t right now), and that would break things.
> Combining
> the participant ID and channel name in the nodepart allows the MIX channel
> to
> control both parts to always fit in a nodepart (restricting the length of
> the
> channel name most likely).
>
>
> kind regards,
> Jonas
> _______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: Standards-unsubscribe at xmpp.org
> _______________________________________________
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.jabber.org/pipermail/standards/attachments/20180604/a803fa99/attachment.html>


More information about the Standards mailing list