On 3 Jun 2018, at 00:33, Steve Kille <steve.ki...@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@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@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.). /K > 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. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
