XMPP Council - 2018-02-07

Updated https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0/edit to match the agenda sent out, and also note a additional votes from November.

Dave, are you also tracking editor actions? if so, can you mark them as done?

jonasw, All of them? :-)

maybe ;-)

I’d have to check

sorry, since my work schedule shifted I won’t be able to take minutes anymore :/. the meetings fall in the last part of my work time and/or commute.

Hi?

you again?

Sorry, I can go again.

Afternoon all. Shall we begin?

sure

Oh, do we have anyopne to take minutes?

Hmmm. OK, then. I'll see what I can craft afterwards.

1) Roll Call

Kev already sent apologies.

.o/

SamWhited, ?

Sorry, having computer trouble. Here by phone.

OK.

2) Advance XEP-0363 to Draft https://xmpp.org/extensions/xep-0363.html

(These first four items are all Last Calls this Council issued and then forgot about until jonasw and SamWhited spotted them and reminded me, sorry!)

I've commented on potential security issues with the quoting of HTTP headers in 363, on list.

Ge0rG, Is that a -1 pending this, then?

I think that a malicious XMPP server _might_ be able to infiltrate a corporate network under some circumstances.

Dave: I suppose so.

Dave: I'm not very confident in my constructed case, but I'd like to have some other experts (Daniel, Sam) have a look at what I fantasized.

Ge0rG, OK - that's fine, by the way, and maybe it's just a case of noting the possibility in the Security Considerations. But if it's a possibility, it should be noted.

And probably just a security note in the XEP ... what you said.

Computer issues fixed; here for real now.

daniel, SamWhited - Any vote for advancing XEP-0363?

Ge0rG, i can't say if this is actually a security issue. but i'm ok with mentioning it in the security considerations

+1 (not that it really matters with Ge0rGs -1)

daniel, Means if its fixed it'll go through.

I'm +1; I haven't seen Ge0rG's email, but if the gist is just "headers should be escaped properly" it seems like mentioning it in the security considerations is reasonable.

daniel: I'm +1 once my concerns are addressed in the XEP, either by a short Security note or by invalidating my attack vector.

either way, the XEP allows encoding things into HTTP headers which would be forbidden by HTTP.

OK. I'm on-list, FWIW, there's feedback I seem to have forgotten about so I'll review that first.

Ge0rG: https://mail.jabber.org/pipermail/standards/2017-November/033936.html this?

So I think a client MUST sanitize the headers

Zash: yes

So, 3) Advance XEP-0352 to Draft

https://xmpp.org/extensions/xep-0352.html

+1

+1

I think it's useful and practical, but I really don't like the weasel-wording in §3.2

I'm +1, noting that Kev has unanswered feedback, so I'm fully expecting him to -1 until that's addressed.

Did the summit provide any insight into better and unified rules for this?

Actually, on second thoughts, I'll do a holding -1 to avoid doubt.

Ge0rG, No, I don't think it did. I'm not convinced that's a bad thing.

I think that CSI goes hand-in-hand with push and message "urgency", and that we should -1 until we have the Big Picture.

I really don't think it makes sense to specify what the server does in this case; there are some obvious ones it could do like the ones listed, but this seems very service dependent.

Ge0rG, There's a risk that trying to do the "right" thing ends up back with SIFT, which is a place I'd rather not go.

Ge0rG, So are you -1'ing this one?

+0

Ge0rG, Thanks.

4) Advance XEP-0234 to Draft

https://xmpp.org/extensions/xep-0234.html

+1

-1

daniel, You noted some unaddressed feedback in the Last Call, is that your reasoning?

yes

i was about to write so

daniel, Excellent, thanks.

It's a complex XEP that I haven't implemented yet (and don't intend to). I will re-read and on-list, probably with +0

daniel, I'll assume you'll watch that and vote +1.

5) Advance XEP-0186 to Draft

https://xmpp.org/extensions/xep-0186.html

+1, though I don't have first-hand experience with it, the XEP looks reasonable.

+1

+1

+1

5) XEP-0198 handling of mismatched h value

https://github.com/xsf/xeps/pull/579

+1

Also see list discussion.

Ahh, I saw the list discussion but not the PR

+1, this seems reasonable

I'm -1, I think a specific stream error needs to be specified, and the behaviour probably could be SHOULD.

I don't like the specific wording (and there is a typo in it), but I'm +1 for adding this disclaimer

(Which is already feedback to the list)

OK.

Dave: I think your reasons for -1 are very well hidden in your mail.

Ge0rG, I'll spell it out more clearly, then.

Dave: thanks

Ge0rG, FWIW, I decided I'd pull this onto the agenda despite thinking it needed more on the basis that it could be applied quicker.

Ah. I've misnumbered and that was item (6). No wonder I'm confused. So:

Dave: do we need to vote on the exact *wording* of the change or just on its merit?

7) Post Summit Discussion

Ge0rG, The technical content. (typos are an editorial thing). But specific error etc is something for us.

Anyone got any comments about the Summit? Anything we think we should act on?

I want server operators to sign the Spam Fighting Manifesto.

I don't think either Board or Council can make that happen.

Ge0rG, I agree that's not a Council thing, though Council can make a statement about it if we want?

(But I can note it in the minutes, too).

Dave: what kind of statement could I expect? The only council-relevant thing is the mention of 0157, IIUC

I'd also like to propose a motion that Council thanks the Summit organisers and sponsors.

+1

That seems reasonable

It was a very productive time, as far as I can see from my laggy remote position.

Ge0rG, We can make a statement about anything, really. "Oooh, that's a good idea". If we think it is.

daniel, Anything on thanking? (It really is a vote, and I'll conveniently ignore Kev's on-list vote since he's one of the organisers in this instance)

+1

daniel, Ta.

8) AOB

Anyone?

9) Next Meeting

+1W?

Let's deprecate XHTML-IM. It's on the agenda, but got skipped again, I think

+1W WFM

+1w

+1w WFM

SamWhited, Quite. I'll put it - I promise - on next week and I'll write something to the list on this today.

SamWhited, Is that OK by you?

I can live with that

SamWhited, Yeah, sorry. Appreciate your patience.

Right, thanks all.

10) Ite, Meeting Est.

Thanks all

Thanks all, thanks Dave

Ge0rG, Link to your Manifesto thing for the minutes?

Dave, https://gist.github.com/ge0rg/2e4accf6950821ca45f743fdf587c08e

(I think it should be a proper repo and not a gist, by the way)

I agree

mathieui: yes

mathieui: it is not a proper repo because I wanted to get feedback from some server admins before making it public, because changing it once people have signed is a no-go

Dave: well done notes :)

Dave: you have qualified for keeping that job :P

Ge0rG, Hmmm. Doing them every week for Board actually meant I figured out what was useful. Although Laura did try to out-do me by adding colours.

Which reminds me to mention my impression from the summit webex that the XSF consists only of white men.

I don't think the XSF is the only place like that unfortunately :(

And I'm just adding to the white male mix

My impression is that the XSF consists of people that want to be part of it.

SouL: just like most others entities/companies with the same issue

pep., that reminds me when at the university people complained about there were no girls (or just a few) studying computer science, for example. That's why I say that :) You cannot force people into things. It's sad to not have diversity, but that's what happens.

That's part of the problem; if you want new people with different backgrounds and different ideas you have to attract them, otherwise the only people who want to be there are the same people who are already there and their friends.

It's not about forcing people into things, it's about recruiting outside of the same small circles.

SouL, you can force people out of things, though

mathieui, completely agree.

(before the 90s, IT was a really mixed domain)

SamWhited: "people that want to be part of it" and can afford it.

Indeed; Ge0rG++, mathieui++

(also, that probably belongs in xsf@ rather than council@, at least)

Ge0rH, mathieuj ?

there was an interesting (and probably very controversial) article about girls on average being more interested in "people" and boys more in "things", leading to a lower number of females in STEM fields, if no external pressure is applied.

I spent a lot of time on hiring and recruiting at my last company, and if you want to hire people other than the kind of people you've already got, you have to put in the effort to make it happen (e.g. not hire friends of current employees, actively search for candidates, etc.). Most people don't put in that effort, with predictable results.

also, the free software community is already largely a self-perpetuating cycle of nerd stereotypes, which does not help

hey peter!

Hey, I'm making a rare appearance here! ;-)

SouL, if the xsf only consists of people who want to be part of it, that means women and non-existent men do not, which is worrying.

Non white was autocorrected weirdly there...

People would also need to know about the XSF

yea

Dave, indeed. I'm just explaining my (little) experience on this topic.

Zash, or, worse, already do and passed us by.

Zash: yeah I feel that's a bigger issue

IMHO it might be easier to change this kind of thing in a company because hiring happens and a hiring manager (as I was) can push for changes. /me shrugs

So, Marketing, the solution to all problems?

Market all the things \o/

The thing where members have to ask to be members, and be voted on, probably produces a ton of bias.

Yup

It's the very definition of self selection

We might advertise that the voting in is largely a formality

^ understatement of the year

Were there ever anybody refused?

Yes, but it's rare.

17:54:54 Ge0rG> Which reminds me to mention my impression from the summit webex that the XSF consists only of white men. only solution: someone’s gotta get an operation.

What's the incentive for keeping the vote in place

pep., for one, to enforce the rule about the % of members of a company

and to prevent some kind of other hostile takeover, I guess, too

You don't need a vote for that to yoy

do you*

(For the company ratio)

I’m not too knowledgeable about the inner workings and implications of a foundation either

Now official: https://github.com/ge0rg/jabber-spam-fighting-manifesto (will announce on operators@ tomorrow)

Ge0rG, one question, though

at jabber.fr we have around a hundred different domains

how do we specify that?

Legally, the XSF is a membership organization. We need some rules about accepting members. Those rules are defined in the Bylaws. Folks are welcome to propose a change to the bylaws.

pep., We've rejected two people in my time. One for refusing to give his/her real name publicly, and one for giving only his real name, claiming we all knew him, and we only knew him by the nickname he had. (That latter was Bear).

mathieui: "jabber.fr + 100 domains" maybe?

mathieui: if you have a public list of the domains, link to it from the third field

Dave: we just need rules then, and when people apply for membership we can enforce the rules if applicable, I fail to find an argument for the vote. Maybe to prevent "hostile takeovers" as mathieui but even then..

Or maybe the vote could be the exception

In my experience, anti-takeover is usually implemented by having the board have longer, overlapping terms.

Zash, That would be useful for other reasons. I did wonder about explicitly trying to sort that out, but I've lacked energy to figure out a sane transition.

Yeah, transition rules can be tricky

how to overlapping terms help againsts takeovers?

If you wanna do a take-over, you need to hijack two meetings

I thought accepting people by voting was related to members choosing the Board and Council.

so for the overlapping period both boards have to come to mutual aggreements?

Hm?

It gives you time to figure out their evil plans, and then the members can call an extra meeting and kick the evil people out.

Zash, there is a period were are to boards in place, what if board A decides to do C and board B decided to not do C?

Or something.

Flow, One board, with members with overlapping terms.

Flow: There's one board

Flow, So each election is for half the board.

ahh, got it

Longer terms also allow people to do more long term planning

Hmm, transitions...

I do wonder if longer council terms would help ... with something.

We'd need the same format right? Maybe not longer but rolling term

Related to earlier discussion: https://www.w3.org/community/w3c-women/

It's not just women really, it's all non-white males, but that's a start

But then if we make a group for them they might complain about segregation :p

In my limited experience, this is not something to talk about but something to act on, which is what I did at my last company. I'm no longer in a hiring role, but learned some valuable lessons.

peter: sure. For now we can try to find a way to transition and make new members feel a bit more welcomed. (See propositions above)

pep.: that sounds like a good start

This should really have been in xsf@

likely so

anybody not ok about me pasting this into the other room?