> 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’. 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). /K _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
