XMPP Council - 2017-02-28

  1. Tobias

    looks like a quite short agenda for today

  2. daniel

    Guess I finally have to read the sasl 2 xep

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

  4. moparisthebest

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

  5. Link Mauve

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

  6. moparisthebest

    ah that's understandable it is quite boring :)

  7. Zash

    What's "abject"

  8. Link Mauve

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

  9. Kev

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

  10. Zash

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

  11. daniel

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

  12. daniel

    if you want to support things like tfa

  13. daniel

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

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

  15. SamWhited

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

  16. SamWhited

    or similar

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

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

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

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

  21. Dave Cridland

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

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

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

  24. SamWhited

    Could we piggy back on that?

  25. Zash

    Didn't SASL2 remove the stream restart?

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

  27. Dave Cridland

    Zash, Yes.

  28. Zash

    But why

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

  30. Dave Cridland

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

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

  32. Dave Cridland

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

  33. Zash

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

  34. Dave Cridland

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

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

  36. Zash

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

  37. Dave Cridland

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

  38. daniel

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

  39. SamWhited

    *oops* not me.

  40. jcbrand


  41. jcbrand

    but now I know

  42. SamWhited waves

  43. jcbrand


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

  45. Tobias

    Kev might know

  46. Kev


  47. Tobias

    I certainly don't

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

  49. SamWhited

    oh wait, maybe Kev's not

  50. SamWhited

    This is confusing

  51. Tobias

    there's a XSF team on trello?

  52. SamWhited

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

  53. Kev

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

  54. SamWhited

    The board's board is under an XSF team

  55. Dave Cridland

    Kev, There's a Board Board too.

  56. SamWhited

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

  57. Kev

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

  58. SamWhited

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

  59. Tobias

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

  60. Tobias

    1) Roll call

  61. Link Mauve

    Hi. o/

  62. SamWhited waves

  63. Dave Cridland

    Bacon, please.

  64. Tobias

    daniel, ping

  65. daniel

    i'm here

  66. Tobias


  67. Tobias

    2) Minute taker

  68. Tobias

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

  69. jcbrand


  70. Tobias


  71. Tobias

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

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

  73. daniel

    where are we currently with the NS bump for carbons?

  74. daniel

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

  75. Tobias

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

  76. Link Mauve

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

  77. daniel

    Link Mauve, are we going to remove that one?

  78. daniel

    some people wanted to leave it in

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

  80. Tobias

    Dave Cridland, is that PR already online?

  81. daniel


  82. daniel


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

  84. Tobias


  85. SamWhited

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

  86. Tobias

    right, will put it on my todo too

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

  88. Dave Cridland

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

  89. daniel

    if that's the only reason

  90. Dave Cridland

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

  91. SamWhited


  92. daniel

    but anyway we should probably discus this in the PRs

  93. Link Mauve

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

  94. Dave Cridland

    daniel, Or even better, on the list.

  95. Link Mauve

    If we decide to accept #434.

  96. daniel

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

  97. daniel

    but lets move on

  98. Tobias

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

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

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

  101. Link Mauve

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

  102. daniel

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

  103. daniel

    or cherry pick flows commit

  104. daniel

    or whatever

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

  106. Dave Cridland

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

  107. Link Mauve

    Tobias, ok, adding it to my list.

  108. Link Mauve

    Dave Cridland, of course.

  109. Tobias


  110. Link Mauve

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

  111. Tobias

    4) Date of next

  112. Dave Cridland

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

  113. Link Mauve

    It does solve the issue.

  114. Dave Cridland

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

  115. Tobias

    5) Date of next

  116. Dave Cridland

    Thank heavens for Last Message Correction...

  117. Tobias

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

  118. Link Mauve

    Dave Cridland, :)

  119. moparisthebest

    any news on xep-368 ? :)

  120. Tobias

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

  121. Link Mauve

    moparisthebest, will vote on list.

  122. Tobias

    does that work for everybody?

  123. SamWhited

    Tobias: WFM

  124. daniel


  125. Dave Cridland


  126. Link Mauve

    Tobias, wfm.

  127. Tobias


  128. Tobias

    6) AOB

  129. SamWhited

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

  130. Dave Cridland


  131. Link Mauve

    SamWhited, oh. :x

  132. Dave Cridland

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

  133. SamWhited

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

  134. Dave Cridland

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

  135. Dave Cridland

    So, my AOB:

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

  137. daniel

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

  138. daniel

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

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

  140. SamWhited

    Dave Cridland: ♡

  141. Tobias

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

  142. daniel

    Tobias, ok. thanks

  143. Zash

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

  144. Dave Cridland

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

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

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

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

  148. Tobias

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

  149. Link Mauve

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

  150. Link Mauve

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

  151. SamWhited

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

  152. SamWhited

    I can make a list on the wiki somewhere

  153. Tobias


  154. Tobias

    Someone having further AOBs?

  155. Link Mauve

    None from me.

  156. SamWhited

    Note that all the outstanding LCs end tomorrow again.

  157. SamWhited

    Just FYI.

  158. Tobias

    right..will do some reading/voting later today

  159. Tobias

    seems there's no further AOB

  160. Tobias bangs the gavel

  161. Tobias

    thanks everybody

  162. Tobias

    thanks jcbrand for writing up minutes

  163. Link Mauve


  164. daniel

    thank you Tobias and jcbrand

  165. Kev

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

  166. daniel

    i'm really not a fan of georgs carbon PR

  167. Kev

    (it = gsoc editor work)

  168. daniel

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

  169. Zash

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

  170. Dave Cridland

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

  171. Kev

    "Not development" tasks certainly aren't.

  172. Kev

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

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

  174. SamWhited


  175. Kev

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

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

  177. daniel

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

  178. SamWhited

    That too

  179. Kev

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

  180. jcbrand

    minutes have been sent out.

  181. Dave Cridland

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

  182. Tobias

    jcbrand, great council minutes, ta :)

  183. jcbrand

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

  184. Dave Cridland

    Oh, I didn't notice. Thanks.

  185. jcbrand

    It's complicated :)

  186. jcbrand

    I have to use two different email addresses

  187. SamWhited

    jcbrand: Thanks again!

  188. jcbrand

    to send them from

  189. jcbrand

    You're welcome SamWhited :)

  190. Tobias

    why that?

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

  192. jcbrand

    and also for the XSF members list

  193. jcbrand

    I thought I'd still get that fixed sometime

  194. jcbrand

    but ja... just working around it for now

  195. Tobias

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

  196. jcbrand

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