XMPP Council - 2018-02-07

  1. Dave

    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.

  2. jonasw

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

  3. Dave

    jonasw, All of them? :-)

  4. jonasw

    maybe ;-)

  5. jonasw

    I’d have to check

  6. jonasw

    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.

  7. Ge0rG


  8. zinid

    you again?

  9. Ge0rG

    Sorry, I can go again.

  10. Dave

    Afternoon all. Shall we begin?

  11. daniel


  12. Dave

    Oh, do we have anyopne to take minutes?

  13. Dave

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

  14. Dave

    1) Roll Call

  15. Dave

    Kev already sent apologies.

  16. Ge0rG


  17. Dave

    SamWhited, ?

  18. SamWhited

    Sorry, having computer trouble. Here by phone.

  19. Dave


  20. Dave

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

  21. Dave

    (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!)

  22. Ge0rG

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

  23. Dave

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

  24. Ge0rG

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

  25. Ge0rG

    Dave: I suppose so.

  26. Ge0rG

    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.

  27. Dave

    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.

  28. Ge0rG

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

  29. SamWhited

    Computer issues fixed; here for real now.

  30. Dave

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

  31. daniel

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

  32. daniel

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

  33. Dave

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

  34. SamWhited

    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.

  35. Ge0rG

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

  36. Ge0rG

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

  37. Dave

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

  38. Zash

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

  39. Ge0rG

    So I think a client MUST sanitize the headers

  40. Ge0rG

    Zash: yes

  41. Dave

    So, 3) Advance XEP-0352 to Draft

  42. Dave


  43. daniel


  44. SamWhited


  45. Ge0rG

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

  46. Dave

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

  47. Ge0rG

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

  48. Dave

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

  49. Dave

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

  50. Ge0rG

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

  51. SamWhited

    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.

  52. Dave

    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.

  53. Dave

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

  54. Ge0rG


  55. Dave

    Ge0rG, Thanks.

  56. Dave

    4) Advance XEP-0234 to Draft

  57. Dave


  58. SamWhited


  59. daniel


  60. Dave

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

  61. daniel


  62. daniel

    i was about to write so

  63. Dave

    daniel, Excellent, thanks.

  64. Ge0rG

    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

  65. Dave

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

  66. Dave

    5) Advance XEP-0186 to Draft

  67. Dave


  68. Ge0rG

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

  69. SamWhited


  70. daniel


  71. Dave


  72. Dave

    5) XEP-0198 handling of mismatched h value

  73. Dave


  74. daniel


  75. Dave

    Also see list discussion.

  76. SamWhited

    Ahh, I saw the list discussion but not the PR

  77. SamWhited

    +1, this seems reasonable

  78. Dave

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

  79. Ge0rG

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

  80. Dave

    (Which is already feedback to the list)

  81. Dave


  82. Ge0rG

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

  83. Dave

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

  84. Ge0rG

    Dave: thanks

  85. Dave

    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.

  86. Dave

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

  87. Ge0rG

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

  88. Dave

    7) Post Summit Discussion

  89. Dave

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

  90. Dave

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

  91. Ge0rG

    I want server operators to sign the Spam Fighting Manifesto.

  92. Ge0rG

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

  93. Dave

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

  94. Dave

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

  95. Ge0rG

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

  96. Dave

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

  97. Ge0rG


  98. SamWhited

    That seems reasonable

  99. Ge0rG

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

  100. Dave

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

  101. Dave

    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)

  102. daniel


  103. Dave

    daniel, Ta.

  104. Dave

    8) AOB

  105. Dave


  106. Dave

    9) Next Meeting

  107. Dave


  108. SamWhited

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

  109. Ge0rG

    +1W WFM

  110. daniel


  111. SamWhited

    +1w WFM

  112. Dave

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

  113. Dave

    SamWhited, Is that OK by you?

  114. SamWhited

    I can live with that

  115. Dave

    SamWhited, Yeah, sorry. Appreciate your patience.

  116. Dave

    Right, thanks all.

  117. Dave

    10) Ite, Meeting Est.

  118. SamWhited

    Thanks all

  119. Ge0rG

    Thanks all, thanks Dave

  120. Dave

    Ge0rG, Link to your Manifesto thing for the minutes?

  121. jonasw

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

  122. mathieui

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

  123. jonasw

    I agree

  124. Ge0rG

    mathieui: yes

  125. Ge0rG

    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

  126. Ge0rG

    Dave: well done notes :)

  127. Ge0rG

    Dave: you have qualified for keeping that job :P

  128. Dave

    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.

  129. Ge0rG

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

  130. pep.

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

  131. pep.

    And I'm just adding to the white male mix

  132. SouL

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

  133. pep.

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

  134. SouL

    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.

  135. SamWhited

    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.

  136. SamWhited

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

  137. mathieui

    SouL, you can force people out of things, though

  138. SouL

    mathieui, completely agree.

  139. mathieui

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

  140. Ge0rG

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

  141. SamWhited

    Indeed; Ge0rG++, mathieui++

  142. mathieui

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

  143. Zash

    Ge0rH, mathieuj ?

  144. Ge0rG

    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.

  145. peter

    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.

  146. mathieui

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

  147. Ge0rG

    hey peter!

  148. peter

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

  149. Dave

    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.

  150. Dave

    Non white was autocorrected weirdly there...

  151. Zash

    People would also need to know about the XSF

  152. mathieui


  153. SouL

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

  154. Dave

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

  155. pep.

    Zash: yeah I feel that's a bigger issue

  156. peter

    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

  157. Zash

    So, Marketing, the solution to all problems?

  158. pep.

    Market all the things \o/

  159. Zash

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

  160. Dave


  161. Dave

    It's the very definition of self selection

  162. Dave

    We might advertise that the voting in is largely a formality

  163. peter

    ^ understatement of the year

  164. pep.

    Were there ever anybody refused?

  165. peter

    Yes, but it's rare.

  166. jonasw

    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.

  167. pep.

    What's the incentive for keeping the vote in place

  168. mathieui

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

  169. mathieui

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

  170. pep.

    You don't need a vote for that to yoy

  171. pep.

    do you*

  172. pep.

    (For the company ratio)

  173. mathieui

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

  174. Ge0rG

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

  175. mathieui

    Ge0rG, one question, though

  176. mathieui

    at jabber.fr we have around a hundred different domains

  177. mathieui

    how do we specify that?

  178. peter

    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.

  179. Dave

    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).

  180. Ge0rG

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

  181. Ge0rG

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

  182. pep.

    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..

  183. pep.

    Or maybe the vote could be the exception

  184. Zash

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

  185. Dave

    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.

  186. Zash

    Yeah, transition rules can be tricky

  187. Flow

    how to overlapping terms help againsts takeovers?

  188. Zash

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

  189. SouL

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

  190. Flow

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

  191. Zash


  192. Zash

    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.

  193. Flow

    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?

  194. Zash

    Or something.

  195. Dave

    Flow, One board, with members with overlapping terms.

  196. Zash

    Flow: There's one board

  197. Dave

    Flow, So each election is for half the board.

  198. Flow

    ahh, got it

  199. Zash

    Longer terms also allow people to do more long term planning

  200. pep.

    Hmm, transitions...

  201. Zash

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

  202. pep.

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

  203. peter

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

  204. pep.

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

  205. pep.

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

  206. peter

    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.

  207. pep.

    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)

  208. peter

    pep.: that sounds like a good start

  209. pep.

    This should really have been in xsf@

  210. peter

    likely so

  211. pep.

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