the vote on whether someone should bother writing the PRs specifically :)
Kev
Pretty sure im-ng should be on there too.
Kev
Or should have been last week, but wasn't.
SamWhitedhas left
vanitasvitaehas left
Dave
Kev, I've been busy, I do apologise. I'll knock this out. FWIW, im-ng was fractionally too late for last week, IIRC. Unless I'm thinking of the week before, and just forgot last week.
Kev
The latter.
jonasw
+1 for the latter because I’m fairly certain that I didn’t do any editor work last week
SamWhitedhas left
danielhas joined
Dave
Oh. Whoops.
SouLhas joined
jerehas joined
Ge0rGhas joined
SamWhitedhas left
jerehas joined
Dave
Right, time.
Kev
Think so.
Dave
1) Roll Call
daniel
hi
Ge0rG
🙋
Dave
SamWhited, ?
Dave
2) Agenda Bashing
Dave
So I've not managed to do an Agenda this week, for which I apologise.
Kev
I would love to bash an Agenda.
Dave
I think we have two CFEs, Kev's IM-NG protoXEP, and... anything else?
jonasw
.oO(piñarta agenda?)
jonasw
Dave, the GC1.0 abolishment vote
Dave
Oh, yes, of course.
Ge0rG
I also have a proposal for MUC self-ping
daniel
i want to register the muc config option for mam
daniel
or at least get the process going / clarify what the process is exactly
Dave
OK - I'm going to guess that between the protoXEP, CFEs, and GC-1.0 we'll probably fill the half hour, but we'll see.
SamWhited
sorry, I'm here
Ge0rG
No need to be sorry.
Ge0rG
Dave: 3) minute taker?
Dave
Ge0rG, Good plan.
Dave
3) Minute Taker
Dave
Either Tedd Sterr will do it or else I will.
Ge0rG
It looks like the abolition of Pidgin is a Board agendum now.
Dave
:-)
Ge0rG
<https://github.com/xsf/xmpp.org/pull/425>
daniel
,oO(can you just get rid of pidgin be removing session support on the server?)
Ge0rG
daniel: it will probably break other clients as well
Dave
Right, bear with me while I figure out which CFEs have completed.
jonasw
Dave, 0131, 0141, 0229 AFAICT
Dave
jonasw, Thanks.
Dave
So with that:
jonasw
(provided you already voted on 0092 and 0122)
Dave
4) Advance XEP-0131 to Final
Dave
jonasw, Yes, we did.
jonasw
good
Dave
This one is SHIM, BTW.
Kev
-1, doesn't have the implementations (and other reasons).
SamWhited
Also -1, this doesn't feel like it fits a need in the ecosystem and doesn't have the implementations. We should kill it instead.
Dave
I'm going to vote on-list for all of these, I warn in advance - however, in the case of SHIM I can't help feeling I'd *like* to ditch it but it's referred to by other XEPs.
jonasw
isn’t it used by PubSub?
Dave
jonasw, Pubsub and XEP-0149.
daniel
i actually implemented this once. but i feel like this is so niche that who ever needs it can just make up their own syntax and/or use the deprecated one. so -1
Ge0rG
I've had a tough fight against generic headers in 0363. -1
Dave
5) Advance XEP-0141 to Final
Dave
Data forms layout, BTW.
Kev
-1 doesn't have the implementations
Zashhas joined
Ge0rG
is that referenced from others as well?
Dave
Ge0rG, Nope. I've seen it used, though, in XEP-0346 implementations.
daniel
-1
Zashhas joined
Ge0rG
-0
SamWhitedhas left
Kev
I'd like to advance 141, but we didn't have the numbers in the CfE, that I saw.
Kev
Someone tell me I'm wrong, by all means.
SamWhited
-1, same reason as Kev, but also think forms is too complex already and we don't need to shoehorn layout information into the document structure.
Dave
5) Advance XEP-0229 to Final
Dave
LZW stream compression
Dave
I do have a vote for this: -1 for implementations and also I don't see a driving need for it.
SamWhited
I have used this and have implementations, but it's underspecified so -1.
Kev
-1
daniel
0
Ge0rG
-1 for the security issues of mixing different data classes into a compressed stream
daniel
Ge0rG, that argument applies to compression in general though?
daniel
not to that particular xep
SamWhited
Either way, we need to figure out what we're doing with 0138 and then this should probably just follow whatever happens with that.
Ge0rG
daniel: it applies to compression in general and thus to this XEP by extension
This is clearly going to need to adapt as we make further decisions, but I'd like to get it under XSF control.
Ge0rG
How could I have missed that submission? on-list
Kev
So I'm +1.
daniel
Ge0rG, I'm just saying it feels 'unfair' to punish the lzw xep instead of 138
Dave
I worry that this might end up the bike shed of bike sheds, but I'm not going to veto, so 0.
Ge0rG
daniel: I agree. Please put 0138 on the next agenda.
Kev
Dave: 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
Ge0rG
I've heard somebody gave a speech, or somesuch.
SamWhited
+1
Kev
daniel: Sure, that's fine (not liking the current form) - but I thought step one was getting some words down that people can disagree with.
Dave
7) Kill GC-1.0
Dave
Kev, "Get a number". :-)
jerehas joined
Ge0rG
obviously +1
Kev
I am, in principle, ok with removing gc1 from 45, but only if we can do so in a way that makes everything better.
daniel
link to pr?
Kev
daniel: There's no PR, this is just raising the idea up a flagpole and seeing who salutes.
Dave
daniel, There's no PR, so this is a vote on the principle.
Kev
i.e. this is a vote on position, rather than standards advancement.
SamWhitedhas left
Ge0rG
I promise to prepare a PR if this vote is accepted. Although I don't promise *when* I will be able to submit it.
SamWhited
I am tentatively +1 on the general idea; can't hurt to see a PR either way.
Kev
I'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.
Dave
I'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.
Ge0rG
We have ~two weeks worth of numbers from prosody.im and yax.im, showing that there was only one client not supporting MUC protocol
Dave
Ge0rG, Right, but that is a different problem to the one I outline.
Kev
Ge0rG: Yes, that's why I'm in principle ok with the idea, as long as it can be done such that nothing existing breaks.
Ge0rG
Dave: 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.
Dave
Ge0rG, In any case, I think I'm keen to see what this would do in practise, so +1 to someone else writing a PR. :-)
daniel
+1
Dave
Ge0rG, 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.
Ge0rG
Dave: I hope that sane clients will handle a presence error from a MUC as "you are not there anymore"
Dave
Ge0rG, As such, when I see what you're aiming to do, it might nudge me into a couter-proposal.
Dave
Ge0rG, That is extremely optimistic of you. Possibly right, too. But certainly optimistic.
Ge0rG
Dave: I don't have a proposal beyond what I wrote on standards@
Ge0rG
Dave: I'm not sure I'm sane enough to fix insane clients. Nor that I want to volunteer my sanity for that goal.
Dave
Ge0rG, Sure. But it might be fun to trial any change and see what clients do.
Ge0rG
Kev: 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.
Dave
Anyway, as I say, I'm in favour of doing this given your evidence thus far.
Kev
Ge0rG: 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.
Ge0rG
Kev: I'm pretty sure I can't fulfill your requirement. And I still think that it's based on a flawed assumption
Dave
SamWhited, I don't think I have a vote from you on this one.
Kev
My 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.
jerehas joined
Dave
SamWhited, Oh, sorry - just spotted that.
Kev
I think it'll come down to what breaks and where.
Ge0rG
Kev: do you consider sending an error to non-joined clients a "break"?
Dave
So we're unanimously in favour of Georg writing a PR we can vote on. :-)
Kev
Ge0rG: Maybe, depending how clients react to it.
Kev
If all clients do a sensible thing, I can probably be talked into it.
Ge0rG
Kev: Alright. Could you please perform a study of the clients that you care about?
Lancehas joined
Kev
Not likely.
Ge0rG
I mean, realistically we'll have to reduce the subset of clients.
Dave
Ge0rG, I know I don't have access to all the clients I'd want to know about.
Ge0rG
I suggest we test all clients that comply with this year's Compliance Suite.
daniel
lol
Dave
Ge0rG, I don't know how clients I actually work with would react.
Dave
Anyway, we've voted, so:
Dave
8) AOB
daniel
whats the process for registering a new muc config option?
Ge0rG
I'd like to put the MUC self-ping suggestion up for a vote-on-principal✎
daniel
can we take a vote and order the registry to include it?
Ge0rG
I'd like to put the MUC self-ping suggestion up for a vote-on-principle ✏
Ge0rG
The 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)
Dave
daniel, Do you know, I've actually no idea. I'll look into the process. I'd expect it's a matter of "document it".
Ge0rG
This one is at least less probable to break all clients.
Dave
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.
Dave
Ge0rG, Looks fine to me. Feels like it could be documented in a new XEP, too.
Ge0rG
Dave: what's wrong with adding a use-case into 0045?
Kev
I'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.
Ge0rG
Kev: not to users, to yourself.
Dave
Kev, Not to users, to occupants.
Dave
Kev, You already have to implement vcard IQs, after all.
Kev
Only to your own occupant JID might be ok.
SamWhitedhas left
daniel
i'm ok with specifying that a ping to self should be handled (and responded to) by the server
Dave
9) Next Meeting
Dave
Same time next week?
SamWhited
WFM
Kev
WFM
daniel
wfm
Ge0rG
WFM
Dave
10) Ite, Meeting est
Ge0rG
The self-ping-to-occupant was the only useful and O(1) way for a client to check whether it's still joined, anyway.
Dave
Once again, sorry for the disorganised lack of agenda,, and thanks for bearing with me.
Ge0rG
Dave: next time we expect an organised lack of agenda
Kev
Thanks all.
Ge0rG
Thanks!
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)
daniel
so apparently this is not the right way to do it
daniel
would you like me to create a full new xep just for this config option?
Dave
That was a long time ago, no wonder I'd forgotten.
daniel
i would just like to find the 'correct way' and then just do it. instead of bike shedding it to death again
Dave
daniel, 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
daniel
and it's up to the registrar to decide whether to accept this?