[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