On Thu, Oct 05, 2017 at 12:20:12PM +0100, Kevin Smith wrote: > > > On 5 Oct 2017, at 11:39, Jonas Wielicki <[email protected]> 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. -- Zash _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
