On 5 Oct 2017, at 12:51, Kim Alvefur <z...@zash.se> wrote: > > On Thu, Oct 05, 2017 at 12:20:12PM +0100, Kevin Smith wrote: >> >>> On 5 Oct 2017, at 11:39, Jonas Wielicki <jo...@wielicki.name> wrote: >>> >>> On Mittwoch, 4. Oktober 2017 21:19:33 CEST Kevin Smith wrote: >>>>>> I think >>>>>> that “presence things with magic side effects” is one of the problems we >>>>>> have with MUC, so adding more such things isn’t what I’d choose when >>>>>> addressing this. >>>>> >>>>> I wholeheartedly agree with the spirit of that. This is a bad feeling I >>>>> have with (3), too. But (2) doesn’t solve the GC1.0 join issue (while (3) >>>>> can, because it depends on a feature var and adds a new child element to >>>>> the presence): if one sends presence updates while desynced from a MUC, >>>>> one will suffer a partial rejoin due to the Group Chat 1.0 legacy cruft. >>>>> >>>>> I thus think that bolting on top of the already existing "presence things >>>>> with magic side effects" is the only way out of this. But I might be >>>>> overlooking something---please let me know if. >>>> >>>> I suspect we can sort out a way to resolve this without quite as much >>>> complexity as 3. Georg’s started a worthwhile discussion here, but I’m sure >>>> these aren’t the only 3 options we can consider. >>> >>> Okay. So what would a more complete solution look like? >>> >>> One idea I have is to use (2), but also specify a new feature and >>> <presence/> >>> payload for MUC (let’s call it <no-join/>). A MUC service would handle it >>> as >>> follows: >>> >>> 1. If the sender is currently joined, the presence is handled as usual. >>> 2. If the sender is currently not joined, *no* GC 1.0 join takes place. >>> Instead, a <presence unavailable/> is sent back, which MAY carry the >>> original status code and message from when the sender was last removed >>> from >>> the MUC and SHOULD include the 'kicked' status code. (In contrast to >>> <rejoin-if-needed/>, this does not rejoin the sender automatically.) >>> >>> Then MUC client implementations just need to tell the directed presence >>> thing >>> that <no-join/> needs to be included in each presence cast to the MUC. >>> >>> MUC services only need to check for <no-join/> in the GC 1.0 handling and >>> advertise the feature. >>> >>> MUC client implementations use the ping to detect whether they are joined. >>> >>> What do you people think? >> >> That sounds simpler to implement than (3), certainly, so it seems preferable >> to me (although if we can get away without presence annotation at all, even >> better). >> >> Two other things for discussion: >> >> 1) Could implementations make gc1 support a configuration option, >> default ‘off’. > > I approve. > >> 2) Could we remove the gc1 compatibility from xep45 and suggest >> people drop it? Interestingly, gc1style joins have no namespace >> associated with them, and no discovery, so it’s probably not a >> namespace bump (I think we’re all going to agree that bumping >> MUC’s namespace would be undesirable). > > I would like to see some statistics on how common GC1 joins are.
More than that, I think you need to know how comman GC1 joins *that were meant to be GC1 joins* are, as opposed to the usual case of a GC1 join triggered accidentally by a presence change. We’d have to be talking about clients that don’t support MUC, and if there are any significant number of those still in the wild I’d be pretty surprised. /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
