[Standards] Another proposal - Handling JIDs for MIX-CORE, MIX-PRESENCE and MIX-PAM

Kevin Smith kevin.smith at isode.com
Mon Jun 4 08:17:40 UTC 2018

On 3 Jun 2018, at 00:33, Steve Kille <steve.kille at isode.com> wrote:
> Sam's message made me realize that none of the variant 1/2/3/4 stuff is
> needed for MIX-CORE.

I’m not at all convinced that this is true. Anything that relies directly on real-JID routing is breaking PMs, and I don’t think disallowing PMs in real-JID rooms is something that’s been generally accepted.

>    There are some things that might be needed in
> MIX-ANON, but let's worry about these in the MIX-ANON spec and keep them out
> of MIX-CORE.

If that were true, I’d go along with it.

> In MIX-CORE, messages/presence go to a channel or are distributed by a
> channel.  There is no participant to participant (PM style) communications.

That sounds like saying that PM communications are handled out of band, but what it really means is that PM communications can’t be achieved.

> I suggest.
> 1.  Messages come from the channel  (channel at domain).   This is what is
> happening as the channel is distributing messages.  Inside each message you
> have a mandatory sender information: (Nick and Bare JID).   There would be
> an elegance to putting this information into the JID, but I do not think it
> is practical and it does not gain you anything.

I might buy ‘it does not gain you anything’, but I don’t see the basis for it not being practical to do so.

> 2.  Presence come from the channel  (channel at domain).   This reflects that
> the channel is distributing presence.  Inside each presence stanza you have
> a mandatory sender information: (Nick and Full JID).

I really dislike the idea of having all the presence information inside a presence stanza. It seems very unidiomatic to have <presence from=X type=‘unavailable’/> mean “One of the clients of one of the users in this channel has gone offline, and there are plenty of other presence from=X that are still online”. This will break assorted things in implementations (e.g. have an optimisation to fold presence updates for CSI? Broken. Have a client that maintains a presence map based on JID? Broken. Have a server that does 163 subscriptions? Broken. etc. etc. etc.).


> That is it.   Very simple.

Very simple, but also not workable, I think.

>   No variant JID addressing.  There are some
> issues for MIX-ANON, but lets worry about these in MIX-ANON, and not make
> the core more complex than it needs to be.

We can’t make mix-core the simple core we’d like it to be on the promise that we fix things in mix-anon if the core itself is broken.


More information about the Standards mailing list