KevThis is clearly going to need to adapt as we make further decisions, but I'd like to get it under XSF control.
Ge0rGHow could I have missed that submission? on-list
KevSo I'm +1.
danielGe0rG, I'm just saying it feels 'unfair' to punish the lzw xep instead of 138
DaveI worry that this might end up the bike shed of bike sheds, but I'm not going to veto, so 0.
Ge0rGdaniel: I agree. Please put 0138 on the next agenda.
KevDave: It might, but I think it's something we have to work on, and there was reasonable (not particularly rough) consensus at the Summit, I think.
daniel+1 to get it under xsf control. but i'm not really sure i like it in it's current form
Ge0rGI've heard somebody gave a speech, or somesuch.
Kevdaniel: Sure, that's fine (not liking the current form) - but I thought step one was getting some words down that people can disagree with.
Dave7) Kill GC-1.0
DaveKev, "Get a number". :-)
KevI am, in principle, ok with removing gc1 from 45, but only if we can do so in a way that makes everything better.
daniellink to pr?
Kevdaniel: There's no PR, this is just raising the idea up a flagpole and seeing who salutes.
Davedaniel, There's no PR, so this is a vote on the principle.
Kevi.e. this is a vote on position, rather than standards advancement.
Ge0rGI promise to prepare a PR if this vote is accepted. Although I don't promise *when* I will be able to submit it.
SamWhitedI am tentatively +1 on the general idea; can't hurt to see a PR either way.
KevI'm fine with seeing a PR, and if you *can* produce one that doesn't break anything I'll be ok with it, but I think that's a big ask and I'm not sure it's possible.
DaveI'm fine with removing "bare" presence as a mechanism for joining a chatroom. However, I worry about what existing clients would do is they fall out of sync and *inadvertantly* join using GC-1.0, and have that then perform a different action.
Ge0rGWe have ~two weeks worth of numbers from prosody.im and yax.im, showing that there was only one client not supporting MUC protocol
DaveGe0rG, Right, but that is a different problem to the one I outline.
KevGe0rG: Yes, that's why I'm in principle ok with the idea, as long as it can be done such that nothing existing breaks.
Ge0rGDave: yes. My position is that it's better to uncover to the user that they were gone than to silently re-join a MUC and probably missing a part of history.
DaveGe0rG, In any case, I think I'm keen to see what this would do in practise, so +1 to someone else writing a PR. :-)
DaveGe0rG, Ah. So yes. But that presumes a client will gracefully handle an unexpected join rejection to a presence stanza they didn't think was a join in the first place.
Ge0rGDave: I hope that sane clients will handle a presence error from a MUC as "you are not there anymore"
DaveGe0rG, As such, when I see what you're aiming to do, it might nudge me into a couter-proposal.
DaveGe0rG, That is extremely optimistic of you. Possibly right, too. But certainly optimistic.
Ge0rGDave: I don't have a proposal beyond what I wrote on standards@
Ge0rGDave: I'm not sure I'm sane enough to fix insane clients. Nor that I want to volunteer my sanity for that goal.
DaveGe0rG, Sure. But it might be fun to trial any change and see what clients do.
Ge0rGKev: I'm not sure whether your position boils down to a -1 essentially, because I can't fix what is broken with MUCs getting out of sync, and GC1 is just a cover-up for it.
DaveAnyway, as I say, I'm in favour of doing this given your evidence thus far.
KevGe0rG: I am trying to be open that I think it's an impossible job, while not wanting to stop you trying if you're convinced you can.
Ge0rGKev: I'm pretty sure I can't fulfill your requirement. And I still think that it's based on a flawed assumption
DaveSamWhited, I don't think I have a vote from you on this one.
KevMy requirement basically being that it's a Draft XEP so we shouldn't break anything that's currently deployed against it?
SamWhited> I am tentatively +1 on the general idea; can't hurt to see a PR either way.
DaveSamWhited, Oh, sorry - just spotted that.
KevI think it'll come down to what breaks and where.
Ge0rGKev: do you consider sending an error to non-joined clients a "break"?
DaveSo we're unanimously in favour of Georg writing a PR we can vote on. :-)
KevGe0rG: Maybe, depending how clients react to it.
KevIf all clients do a sensible thing, I can probably be talked into it.
Ge0rGKev: Alright. Could you please perform a study of the clients that you care about?
Ge0rGI mean, realistically we'll have to reduce the subset of clients.
DaveGe0rG, I know I don't have access to all the clients I'd want to know about.
Ge0rGI suggest we test all clients that comply with this year's Compliance Suite.
DaveGe0rG, I don't know how clients I actually work with would react.
DaveAnyway, we've voted, so:
danielwhats the process for registering a new muc config option?
Ge0rGI'd like to put the MUC self-ping suggestion up for a vote-on-principal
danielcan we take a vote and order the registry to include it?
Ge0rGI'd like to put the MUC self-ping suggestion up for a vote-on-principle
Ge0rGThe one from here: https://mail.jabber.org/pipermail/standards/2018-April/034763.html
daniel(since changing the xep45 has been rejected by council members who still serve this year)
Davedaniel, Do you know, I've actually no idea. I'll look into the process. I'd expect it's a matter of "document it".
Ge0rGThis one is at least less probable to break all clients.
Davedaniel, I don't think "changing xep45" is quite the same as "adding a new option". Servers add new options all the time, so unless it's changing existing behaviour, a XEP defining the additional behaviour should be uncontentious.
DaveGe0rG, Looks fine to me. Feels like it could be documented in a new XEP, too.
Ge0rGDave: what's wrong with adding a use-case into 0045?
KevI'm fine with adding a self-ping to MUC to check you're there. I'm not ok with intercepting 199 pings to users and replying from the server.
Ge0rGKev: not to users, to yourself.
DaveKev, Not to users, to occupants.
DaveKev, You already have to implement vcard IQs, after all.
KevOnly to your own occupant JID might be ok.
danieli'm ok with specifying that a ping to self should be handled (and responded to) by the server
Dave9) Next Meeting
DaveSame time next week?
Dave10) Ite, Meeting est
Ge0rGThe self-ping-to-occupant was the only useful and O(1) way for a client to check whether it's still joined, anyway.
DaveOnce again, sorry for the disorganised lack of agenda,, and thanks for bearing with me.
Ge0rGDave: next time we expect an organised lack of agenda
daniel> I don't think "changing xep45" is quite the same as "adding a new option". Servers add new options all the time, so unless it's changing existing behaviour, a XEP defining the additional behaviour should be uncontentious.
well you vetod https://github.com/xsf/xeps/pull/204 last time. that’? what i meant by 'changing the xep'
daniel(re config option for muc)
danielso apparently this is not the right way to do it
danielwould you like me to create a full new xep just for this config option?
DaveThat was a long time ago, no wonder I'd forgotten.
danieli would just like to find the 'correct way' and then just do it. instead of bike shedding it to death again
Davedaniel, Registry is at https://xmpp.org/registrar/formtypes.html#http:--jabber.org-protocol-mucroomconfig and the submission process is https://xmpp.org/extensions/xep-0068.html#registrar-reg-formtypes-process
danieland it's up to the registrar to decide whether to accept this?