XMPP Council - 2017-02-28

  1. moparisthebest has left

  2. Lance has left

  3. Lance has joined

  4. Lance has left

  5. Lance has joined

  6. Lance has left

  7. Lance has joined

  8. Lance has left

  9. Lance has joined

  10. Lance has left

  11. Lance has joined

  12. Lance has left

  13. Lance has joined

  14. jere has left

  15. jere has joined

  16. Lance has left

  17. Lance has joined

  18. jere has left

  19. jere has joined

  20. Lance has left

  21. Lance has joined

  22. jcbrand has joined

  23. jere has joined

  24. jcbrand has left

  25. moparisthebest has joined

  26. SamWhited has left

  27. Lance has left

  28. Flow has joined

  29. daniel has left

  30. daniel has joined

  31. daniel has left

  32. daniel has joined

  33. Tobias has joined

  34. jcbrand has joined

  35. ralphm has joined

  36. jcbrand has left

  37. Kev has joined

  38. Zash has left

  39. daniel has left

  40. daniel has left

  41. daniel has joined

  42. daniel has left

  43. daniel has joined

  44. daniel has left

  45. daniel has joined

  46. Lance has joined

  47. daniel has left

  48. daniel has joined

  49. daniel has left

  50. daniel has joined

  51. jcbrand has left

  52. daniel has left

  53. daniel has joined

  54. ralphm has left

  55. jayaura has joined

  56. daniel has left

  57. daniel has joined

  58. ralphm has left

  59. daniel has left

  60. daniel has joined

  61. jere has joined

  62. jere has left

  63. Lance has left

  64. jere has joined

  65. jcbrand has joined

  66. Tobias

    looks like a quite short agenda for today

  67. jayaura has joined

  68. jayaura has joined

  69. Lance has joined

  70. daniel has left

  71. jere has left

  72. jere has joined

  73. daniel has left

  74. Lance has left

  75. jayaura has joined

  76. jere has left

  77. jayaura has joined

  78. Lance has joined

  79. Lance has left

  80. Flow has left

  81. daniel

    Guess I finally have to read the sasl 2 xep

  82. SamWhited

    I read it, but am still not sure how I feel about it. Did an implementation too; felt like there were more element names than there needed to be and that made it tricky to build a state machine to handle everything. Probably not a reason to block, it just felt very incomplete.

  83. moparisthebest

    Link Mauve 's voting alarm did not seem to work :)

  84. Link Mauve

    moparisthebest, I did start reading it yesterday evening, but didn’t finish before being too sleepy to continue.

  85. moparisthebest

    ah that's understandable it is quite boring :)

  86. Zash

    What's "abject"

  87. Link Mauve

    Nah, I blame the pancakes I had before. :p

  88. Kev

    Zash: Extreme(ly bad). e.g. Abject horror.

  89. Zash

    "You don't have an English dictionary installed." it says

  90. Lance has joined

  91. jayaura has joined

  92. jayaura has joined

  93. daniel

    SamWhited, i'm not sure if it can be made easier

  94. daniel

    if you want to support things like tfa

  95. daniel

    i'm honestly not familiar enough with sasl and it's edge cases to judge that

  96. SamWhited

    daniel: I think it can just by changing a few element names; my issues were mostly XML layer stuff. Eg. I get a <challenge> and send a <response>, but then in the second step I get an <additional-data> and send a <next-authenticate>

  97. SamWhited

    So now I can't just have a valid state in the state machine for "expect <challenge>"

  98. SamWhited

    or similar

  99. SamWhited

    Alternatively, although I think this one is likely to have a good reason behind it, I'm not 100% sure why we don't just advertise the next set of challenges as a new stream feature; XMPP already has the ability to advertise multiple features.

  100. SamWhited

    If it's just to merge the final SASL response and the mechanisms list, I'm not sure that's necessary here; it just felt complicated (although I'm also all for saving round trips where possible, I'm just not sure this actually helps much). I dunno, just thinking out loud though, these might not actually be problems.

  101. Dave Cridland

    SamWhited, If you send a <response/>, your possible outcomes are <success/>, <continue/>, or <challenge/> - not sure there's much I can do to make that simpler.

  102. Dave Cridland

    SamWhited, As for the features versus other stuff in <continue/>, we could make those stream features (sorta), but we need to send them then because things like "You need to change your password now", or "You need to perform 2FA" are very much per-account.

  103. Dave Cridland

    On the plus side, a small change means I can get rid of the "=" wart, I think.

  104. SamWhited

    Dave Cridland: Yah, that makes sense, I'm not sure it's actually a problem. It was just a minor pain point when I was playing around with implementing it.

  105. SamWhited

    WRT adding stuff to stream features, I just meant that after you negotiate the first round, couldn't you *already* just advertise <mechanisms> again with new mechanisms in the stream features? The second level of negotiation is sort of already implemented

  106. SamWhited

    Could we piggy back on that?

  107. Zash

    Didn't SASL2 remove the stream restart?

  108. Dave Cridland

    SamWhited, I'd feel more comfortable with the <continue/> are if we had actual designs for what happens next, in general. But "maybe".

  109. Dave Cridland

    Zash, Yes.

  110. Zash

    But why

  111. SamWhited

    We don't need a stream restart, do we? Eg. if you don't do a stream restart you're free to continue negotiating features from the list (so maybe they could even be advertised together; <mechanisms> and <secondary-mechanisms> or something)

  112. Dave Cridland

    Zash, It's only an issue if a SASL-negotiated security layer is negotiated.

  113. SamWhited

    and if a security layer is negotiated, do a restart and just list the secondary mechanisms in a new <mechanisms> feature (I'm not sure if this actually simplifies anything, but it would mean I don't have to implement retries if my XMPP library already does features)

  114. Dave Cridland

    Zash, I may be wrong, here, but I don't think there's any current XMPP server that supports SASL security layers.

  115. Zash

    Does this mean the server must offer *all* features from the start, even features that require authentication?

  116. Dave Cridland

    Zash, This is a good argument for making the <continue/> and indeed <success/> spit out the stream features.

  117. Dave Cridland

    Zash, And there's no reason it can't, and no reason to make that need a stream restart (and accompanying round-trip).

  118. Zash

    How was it, was the specs clear on who could send stream features and when?

  119. Dave Cridland

    Zash, I mean, we can change SASL2 (if adopted) to do this. Not "we can already".

  120. Lance has left

  121. daniel

    Did anyone ping jcbrand to inform him that council meeting is today and not tomorrow?

  122. SamWhited

    *oops* not me.

  123. jcbrand


  124. jcbrand

    but now I know

  125. SamWhited waves

  126. jcbrand


  127. SamWhited

    Tobias, ralphm: I'm pretty sure one of you is the admin of the XSF Trello team; any chance you could create me an editors board? (also possibly move the Council board under the XSF team so that it's in the same location as the board board)

  128. Tobias

    Kev might know

  129. Kev


  130. Tobias

    I certainly don't

  131. SamWhited

    Ah yes, Kev appears to be an admin too… could you create me an editors board under the XSF team (where the board board lives)?

  132. SamWhited

    oh wait, maybe Kev's not

  133. SamWhited

    This is confusing

  134. Tobias

    there's a XSF team on trello?

  135. SamWhited

    If the little chevron's mean "admin", ralphm is the only one

  136. Kev

    I didn't know there was an XSF team in Trello, I thought there was just the standalone Council board.

  137. SamWhited

    The board's board is under an XSF team

  138. Dave Cridland

    Kev, There's a Board Board too.

  139. SamWhited

    (ah yes, I was looking at the wrong one; Kev is only an admin of the standalone council board)

  140. Kev

    If there's an XSF team I should almost certainly be an admin of it, but I'm not.

  141. SamWhited

    Maybe when ralphm's next online he can create me a board (and add you as an admin)

  142. Tobias

    right...but until then we could enjoy ourselves with a fancy council meeting

  143. Tobias

    1) Roll call

  144. Link Mauve

    Hi. o/

  145. SamWhited waves

  146. Dave Cridland

    Bacon, please.

  147. Tobias

    daniel, ping

  148. daniel

    i'm here

  149. Tobias


  150. Tobias

    2) Minute taker

  151. Tobias

    jcbrand, you're taking minute notes and send them out afterwards, right?

  152. jere has joined

  153. jcbrand


  154. Tobias


  155. Tobias

    3) PR: Clarify CSI and Carbons state after SM resumption

  156. Tobias

    Flow created PRs which clarify things, and asked for council to review https://github.com/xsf/xeps/pull/427 and https://github.com/xsf/xeps/pull/428 . Would be nice if people could do so.

  157. daniel

    where are we currently with the NS bump for carbons?

  158. daniel

    for now (regarding the other changes) it isn't necessary?

  159. Tobias

    phew, good question. Haven't read through all the feedback on the carbons LC yet

  160. Link Mauve

    daniel, it already needs one, for the removal of <private/>.

  161. daniel

    Link Mauve, are we going to remove that one?

  162. daniel

    some people wanted to leave it in

  163. Dave Cridland

    daniel, Georg Lukas has decided to actually put together a PR as a concrete proposal; I've not seen much feedback on that yet.

  164. Tobias

    Dave Cridland, is that PR already online?

  165. daniel


  166. daniel


  167. Dave Cridland

    daniel, FTR, I'm happy if we bump the namespace and do whatever, as long as implementors are likely to follow that and not stick to the old namespace. SO I'm keen to see some feedback.

  168. Tobias


  169. SamWhited

    oh hey, there's a rendered version; I guess I don't have any excuse for not reading it anymore. Will do that.

  170. Tobias

    right, will put it on my todo too

  171. daniel

    Dave Cridland, i can live with a bump but i'm not sure if it's worth doing only to get rid of <private>

  172. Dave Cridland

    SamWhited, You've reminded me of some AOB. Thanks.

  173. daniel

    if that's the only reason

  174. Dave Cridland

    daniel, Indeed; but Georg has added some other stuff.

  175. SamWhited


  176. daniel

    but anyway we should probably discus this in the PRs

  177. Link Mauve

    daniel, the rules definition from Ge0rG are much more of a reason to bump the namespace.

  178. Dave Cridland

    daniel, Or even better, on the list.

  179. Link Mauve

    If we decide to accept #434.

  180. daniel

    Link Mauve, ok if the rules are a reason it's fine with me.

  181. daniel

    but lets move on

  182. Tobias

    4) georg opened an PR on MUC, https://github.com/xsf/xeps/pull/436

  183. Tobias

    as it's draft it requires council approval, so i suggest council members give it a review and we'll vote on in next week so he'd have a chance to incorporate review feedback early on

  184. Link Mauve

    (Still on 3), I would suggest to ask #428 to not bump the namespace, and to let the editor bump it manually once all of the changes are gathered.)

  185. Link Mauve

    (In the past we’ve had release candidates for some XEPs.)

  186. daniel

    yes or ask georg to put the same phrasing in his PR

  187. daniel

    or cherry pick flows commit

  188. daniel

    or whatever

  189. SamWhited

    Doesn't matter to me; I'd prefer just to have it bump the namespace and I'll merge several changes (if there are others) and then do a collective revision bump.

  190. Dave Cridland

    Link Mauve, I'd rather bump it knowing it might well bump some more than risk incompatible deployments.

  191. Link Mauve

    Tobias, ok, adding it to my list.

  192. Link Mauve

    Dave Cridland, of course.

  193. Tobias


  194. Link Mauve

    Tobias, actually I know this topic quite well, so I’m +1 on 4).

  195. Tobias

    4) Date of next

  196. Dave Cridland

    On #436, I think this needs some security considerations, in particular around replacing and/or removing client-added <x/> stuff.

  197. Link Mauve

    It does solve the issue.

  198. Dave Cridland

    Tobias, Is Date Of Next (4) as well?

  199. Tobias

    5) Date of next

  200. Dave Cridland

    Thank heavens for Last Message Correction...

  201. Tobias

    Dave Cridland, no, it says 5) here ;)

  202. Link Mauve

    Dave Cridland, :)

  203. moparisthebest

    any news on xep-368 ? :)

  204. Tobias

    that would be 2017-03-08, 16:00 UTC

  205. Link Mauve

    moparisthebest, will vote on list.

  206. Tobias

    does that work for everybody?

  207. SamWhited

    Tobias: WFM

  208. daniel


  209. Dave Cridland


  210. Link Mauve

    Tobias, wfm.

  211. Tobias


  212. Tobias

    6) AOB

  213. SamWhited

    WRT 0368: I think the council voting period is over, doesn't that mean Link Mauve's vote is an implicit +0?

  214. Dave Cridland


  215. Link Mauve

    SamWhited, oh. :x

  216. Dave Cridland

    SamWhited, Voting period ends tomorrow, I *think*?

  217. SamWhited

    Oh right, it's Tuesday. Sounds good to me.

  218. Dave Cridland

    SamWhited, I know, it's confused me, too.

  219. Dave Cridland

    So, my AOB:

  220. daniel

    fwiw i'm going to vote +1 on #436. i'm not sure why this particular change will require security considerations. i agree that the <x/> element might deserve some. but that's not triggered by that change alone

  221. daniel

    dave can still -1 if there is something i'm missing

  222. daniel

    where should we vote for that PR by the way? github?

  223. Dave Cridland

    Given GSoC, does the Editor team wish to see if there are any complex bits of Editor automation that might be GSoC project ideas? I don't know if they might count, but perhaps discussion between the Editors and the GSoCcer-in-chief (Kev) might resolve that question.

  224. SamWhited

    Dave Cridland: ♡

  225. Tobias

    daniel, i'll call for votes next week, then either in the meeting or the minute notes for that meeting

  226. daniel

    Tobias, ok. thanks

  227. Zash

    Take the md2xep/xep2md hacks I hacked and make another diff viewer?

  228. Dave Cridland

    I was thinking, for example, of pre-rendering PRs, maybe re-visting the diffs, and so on.

  229. SamWhited

    I love this idea; I still want Travis to have a deploy step so I don't have to manually log onto the server and type things wrong and break stuff.

  230. Dave Cridland

    I do appreciate it's not "normal" GSoC fare, so I'm not sure it counts, but it feels like valuable work to me.

  231. Tobias

    all sounds sensible, we could probably put a "XSF" project on the GSoC project ideas page and put ideas there, if they have potential mentors

  232. Tobias

    although keep in mind the project ideas should be enough to fill a GSoC term

  233. Link Mauve

    Tobias, depending on whether the student is more of a sysadmin type, it may actually take a full term.

  234. Link Mauve

    But it should have clear goals, set by the student.

  235. SamWhited

    I think we have plenty of broken stuff or automat-able stuff in the build process to keep an ops-y student busy

  236. SamWhited

    I can make a list on the wiki somewhere

  237. Tobias


  238. Tobias

    Someone having further AOBs?

  239. Link Mauve

    None from me.

  240. SamWhited

    Note that all the outstanding LCs end tomorrow again.

  241. SamWhited

    Just FYI.

  242. Tobias

    right..will do some reading/voting later today

  243. Tobias

    seems there's no further AOB

  244. Tobias bangs the gavel

  245. Tobias

    thanks everybody

  246. Tobias

    thanks jcbrand for writing up minutes

  247. jere has left

  248. jere has joined

  249. Link Mauve


  250. daniel

    thank you Tobias and jcbrand

  251. Kev

    Dave Cridland: It's not immediately obvious to me that it's a bad idea, although it does need some work

  252. daniel

    i'm really not a fan of georgs carbon PR

  253. Kev

    (it = gsoc editor work)

  254. daniel

    these rules are way too complex and involve rules for XEPs that are hopefully going to go away soon

  255. Zash

    I would be happy if the rules for things were simpler. :)

  256. Dave Cridland

    Kev, Definitely needs some thought. I'm also not clear if "not really development" tasks are within the scope.

  257. Kev

    "Not development" tasks certainly aren't.

  258. Kev

    But as long as it's development of tools we use, it seems fair game.

  259. SamWhited

    daniel: Agreed; I'm not sure every XEP ever written should have its carbons rules defined in the carbons spec anyways. If there needs to be interaction, the other XEP seems like a better place (so when you're implementing, eg. direct MUC invitations, then you can read about and deal with carbons interaction

  260. SamWhited


  261. Kev

    Not traditionally the sort of thing the XSF's done in GSoC, but it seems fair game.

  262. Dave Cridland

    Kev, Indeed. There's plenty of development workload here, mind, but it's not exactly traditional. Might be worth flagging it with Google and getting a feel from them?

  263. daniel

    SamWhited, yes. or trigger that with simple <copy/> and/or <no-copy/> hints

  264. SamWhited

    That too

  265. Kev

    Dave Cridland: I'm comfortable making a call on it once I see an idea fleshed out.

  266. jcbrand

    minutes have been sent out.

  267. Dave Cridland

    jcbrand, Can you forward those minutes to standards@ as well, please?

  268. Tobias

    jcbrand, great council minutes, ta :)

  269. jcbrand

    Dave Cridland I sent them to council@xmpp.org and standards@xmpp.org

  270. Dave Cridland

    Oh, I didn't notice. Thanks.

  271. jcbrand

    It's complicated :)

  272. jcbrand

    I have to use two different email addresses

  273. SamWhited

    jcbrand: Thanks again!

  274. jcbrand

    to send them from

  275. jcbrand

    You're welcome SamWhited :)

  276. Tobias

    why that?

  277. jcbrand

    I use lists<at>opkode.com to subscribe to lists but somewhere on the wiki I gave my normal email address and that got then used to whitelist me for the council email address

  278. jcbrand

    and also for the XSF members list

  279. jcbrand

    I thought I'd still get that fixed sometime

  280. jcbrand

    but ja... just working around it for now

  281. Tobias

    there's probably some mailman admin that could fix that for you :)

  282. jcbrand

    Yes, if there's someone here who can help I'd appreciate it, otherwise I'll ask around sometime

  283. Neustradamus has left

  284. Neustradamus has joined

  285. Lance has joined

  286. Tobias has joined

  287. Neustradamus has left

  288. Neustradamus has joined

  289. SamWhited has left

  290. Lance has left

  291. Kev has left

  292. jcbrand has left

  293. Lance has joined

  294. SamWhited has left

  295. jcbrand has left

  296. Lance has left

  297. daniel has left

  298. Lance has joined

  299. Lance has left

  300. Lance has joined

  301. Lance has left

  302. Lance has joined

  303. Lance has left

  304. Lance has joined

  305. Lance has left

  306. Lance has joined

  307. jere has joined

  308. jere has joined

  309. Lance has left

  310. Lance has joined

  311. Lance has left

  312. Lance has joined

  313. SamWhited has left

  314. daniel has left

  315. daniel has joined

  316. jcbrand has joined

  317. jcbrand has left

  318. jayaura has joined

  319. daniel has left

  320. daniel has joined

  321. jcbrand has joined

  322. daniel has left

  323. daniel has joined

  324. jayaura has joined

  325. Lance has left

  326. Lance has joined

  327. daniel has left

  328. jcbrand has left

  329. Lance has left

  330. Tobias has left

  331. Tobias has joined

  332. daniel has joined

  333. jere has left

  334. jere has joined

  335. moparisthebest has joined

  336. Lance has joined

  337. SamWhited has left

  338. SamWhited has joined

  339. SamWhited has joined

  340. jayaura has left

  341. daniel has left

  342. daniel has joined

  343. jayaura has joined

  344. daniel has left