[Standards] Addressing for IQs in MIX-CORE

Dave Cridland dave at cridland.net
Mon Jun 4 15:03:04 UTC 2018

On 4 June 2018 at 14:37, Kevin Smith <kevin.smith at isode.com> wrote:

> On 4 Jun 2018, at 12:15, Dave Cridland <dave at cridland.net> wrote:
> >>
> >>
> >>
> >> On 4 June 2018 at 11:37, Steve Kille <steve.kille at isode.com> wrote:
> >>
> >> To support IQs in MIX-CORE, there needs to be an addressing  and routing
> >> scheme.
> >>
> >> I am proposing that this uses a different scheme to messages from the
> >> channel (this is Kev's variant 4).
> >>
> >> The rationale for having a different scheme is that you want to be able
> to
> >> distinguish from a stanza that comes from the channel, from a stanza
> (IQ)
> >> that is relayed by the channel.
> >
> >
> > I think that's a false dichotomy. <snip/>
> I think calling out the language here might be a fair call (although I
> don’t find it too confusing), but I think the underlying dichotomy is still
> there. Some stanzas are sent in the context of fanout to potentially all
> participants, and some are sent to be distributed in private to a single
> participant.

That's somewhat different - but even here, you're arguing to change the
*from* address depending on where it's been sent *to*?

> >> A message distributed by the channel would come from:
> >>     channel at domain/stable-participant-id
> >>
> >> Bare JID is the channel, reflecting that the message comes from the
> channel.
> >>
> >> An IQ message being relayed by the channel would come from:
> >>     stable-participant-id#channel at domain/resource
> >>
> >> Bare JID reflects the sender, which will enable the receiver to clearly
> >> distinguish that this is not coming from the channel.
> >>
> >> We want to use this scheme for PMs (MIX-ANON), and here the difference
> >> becomes more important.   You want to clearly distinguish messages from
> the
> >> channel from PMs, and this approach gives a framework to achieve this.
> >>
> > So type='groupchat' is no longer enough?
> Yes, that’s surprising isn’t it?
> I came to this realisation a couple of days ago, not just that it’s no
> longer enough, but that it never was really adequate and definitely not
> ideal.
> A few reasons:
> * Elsewhere in XMPP, the ‘to’ alone is used to determine which entity
> receives a stanza (I’m terminating entities at the user, not each of their
> devices, for these purposes). That here the difference between sending to a
> whole group of people and a single person is predicated not on the address,
> but the message type, is cause for us to think twice.

I'm not sure how the to address isn't still governing how receives the
stanza. You're arguing for changing the from here, aren't you?

> * I have seen multiple bugs from people who are not XMPP-naive in this
> area, because it’s very easy to slip when the to no longer gives you
> addressing (including security issues). This makes it easy to shoot
> yourself in the foot.

Same - a message stanza from A to B has been sent from A to B. The type
indicates who *else* has received this. No?

> * Even where it doesn’t end up in a bug, I’ve seen bad UX resulting from
> this.
> * Querying a MAM archive becomes ‘interesting’ when you want to query just
> room messages, or just PMs with a particular occupant

This is an interesting and valid point, i think. I'm not convinced it's
outweighing the address altering depending on the traffic used though.

> there are others, but this is a reasonable flavour, I think.
> Now, one might assert that it’s not worth changing this in MUC, but in MIX
> where we have the chance to avoid all these issues it seems worth giving
> serious thought to alternatives.

Absolutely - but I'd argue we want the addressing consistent irrespective
of the traffic.

> /K
> _______________________________________________
> 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/826d6b7c/attachment.html>

More information about the Standards mailing list