XMPP Council - 2018-01-24

  1. jonasw

    council meeting is at 1600Z?

  2. Kev

    Sounds about right. I admit I've become completely reliant on the minutes-in-advance already.

  3. jonasw


  4. Kev sighs

  5. Kev

    Agenda in advance.

  6. jonasw


  7. jonasw

    that makes sense :)

  8. Kev

    I'm ill, don't pick on me :p

  9. jonasw

    I won’t, I promise

  10. jonasw

    also, get well soon

  11. Kev

    Ta. Only a cold, but it's getting old.

  12. jonasw

    ancient colds are the worst; today’s immune systems just aren’t used to it anymore ;)

  13. Dave

    Sorry, I got sidetracked yesterday while trying to do those minutes-in-advance. They *are* good, but I need to block the time out on my calendar to egt them done, I think.

  14. Ge0rG

    Dave: if you finish them until 1600Z, you can just paste them and we are done in time.

  15. Dave

    Ge0rG, Yeah, but doing them 24 hours ahead (as was my intent) means Council folks are hopefully able to vote in the meeting.

  16. Dave

    Wait, I said minutes too. I meant Agenda, if that wasn't clear.

  17. Dave

    Speaking of minutes, anyone want to do those this week?

  18. Ge0rG

    Dave: I can do them if there are no voices from the floor.

  19. Ge0rG

    Or... from the peanut gallery.

  20. Dave

    Ge0rG, Thanks, but I'm hoping one of the many people here can take them on...

  21. Ge0rG

    I'm sitting in a train and it's rather calm. I really hope there is no reservation for my seat, though.

  22. Kev


  23. Dave

    I've preemptively updated the Spreadsheet of Unofficial Doom with the two PRs which are subject to a vote, though I note that #576 might not actually need a vote as such.

  24. Dave

    And yes.

  25. Dave

    'tis time.

  26. Dave

    1) Role Call:

  27. SamWhited


  28. Dave

    I'll assume Kev and Ge0rG are here. daniel ?

  29. Dave

    I'll assume no daniel then.

  30. Dave

    2) Minutes

  31. Dave

    Anyone from the floor?

  32. Dave

    Otherwise, I'll take Ge0rG up on the offer, then.

  33. Dave

    Ge0rG, That OK?

  34. daniel

    Sorry I'm here now

  35. Ge0rG

    Dave: sure

  36. SamWhited

    I'd like to discuss deprecating XHTML-IM again at some point, I think the previous councils concerns were addresssed and the card has been sitting there since then.

  37. Dave

    SamWhited, That's true.

  38. Dave

    3) Outstanding Votes

  39. Dave

    daniel, I'm missing one from you on the Client Key Support ProtoXEP, I think.

  40. daniel

    I'm +1 on that

  41. daniel

    Unless you want me to write that on list

  42. Dave

    daniel, No, here is fine. And you're voting -1 on TOTP 2FA? (You said "inclined to" on the list)

  43. daniel

    No I'm +1 on that as well

  44. Dave

    Kev, My understanding is you're witholding your vote on '387 until that's been resolved?

  45. Kev

    My original vote was +1 pending the merging of the PR.

  46. Kev

    In an ideal world I'd like to stick to that.

  47. Ge0rG

    Do we need to vote on making jonasw the new author?

  48. Dave

    Kev, Conditional voting has yet to be implemented in the Spreadsheet of Unofficial Doom, so I'll just say you're not yet voting and hope we resolve it all.

  49. Kev

    Ge0rG: I don't think so, as long as Sam hasn't changed his mind about stepping down.

  50. Dave

    Ge0rG, I don't think so, but I'd like to be clear we're all happy with that, hence:

  51. Kev

    Ge0rG: Some formal action to replace an author from Council would be sensible (although I'm not sure we have or need process), but I don't think that's what's happening here, if Sam asked for a volunteer, and Jonas volunteered.

  52. Ge0rG

    Jonas volunteered, but is currently busy so he can't merge the PR. If we approve that decision (do we need to?), he promised to merge the PR, and then we have all the votes needed.

  53. Dave

    4) #576: XEP-0387: Add myself as author and move back to Proposed

  54. Dave

    Anyone object to this? (It's basically Jonas taking authoriship)

  55. SamWhited

    I'm fine with Jonas taking over

  56. Kev

    I've not reviewed, but if it's Jonas becoming Editor, I'm fine with it

  57. Ge0rG

    author, not editor

  58. Dave


  59. Kev

    Don't pick on me, I'm ill :p

  60. Ge0rG

    just clarifying :)

  61. Ge0rG

    +1 to #576

  62. Kev

    But yes, Author.

  63. Dave

    I hear no objections, anyway.

  64. Kev

    FWIW, I think Council should (not today) try to reach a consensus on advice to Jonas for what these should be going forward.

  65. Kev

    I quite like my idea of explicitly splitting between "Best we have" and "State of the network".

  66. Dave

    Kev, "These"?

  67. Dave

    Kev, Oh, Compliance Suites.

  68. Kev

    These = Compliance suites that may or may not really be compliance suites.

  69. Dave

    Kev, Yeah. I think it might be an amusing hour's chat at the Summit, actually.

  70. Kev

    I think the point is right that it's useful to give advice to people who don't care about public network interop, but want the best we have to offer.

  71. Kev

    (Daniel's, I think)

  72. Kev

    But also I think it's important we don't discourage new implementors who want interop by not representing the backwards-compat needed.

  73. Kev

    So being explicit about both sounds ideal to me.

  74. Ge0rG

    Are we voting on #576?

  75. Dave

    Ge0rG, We sort of did. I asked for objections and nobody gave any. I'm logging it as a vote even though it isn't really.

  76. Dave

    5) #559: XEP-0045: Specify 333 stats code

  77. Ge0rG


  78. Dave

    https://github.com/xsf/xeps/pull/559 if you prefer.

  79. jonasw


  80. jonasw

    I’ll merge my authorship for XEP-0387; shall I merge Kevs PR while I’m at it and move it to draft, too?

  81. jonasw

    (sorry, I’m a bit late, I was busy with work stuff)

  82. Dave

    I think I'm +1. I'm not convinced that this isn't a kick, and I'm not convinced kicks are solely for bad behaviour, but this does no harm.

  83. Ge0rG

    jonasw: yes, you can merge that PR.

  84. Kev

    Haha, what a well-worded MAY MUST.

  85. Ge0rG

    In that case, we are missing Sam's voice (as Council member) for the post-PR 387.

  86. Kev

    +1. I don't think it's harmful, although I think it's really a Kick.

  87. Dave

    jonasw, I'll give you a massive list of stuff to do as Editor in a bit, too. :-)

  88. Ge0rG

    IIRC everybody else has voted +1 for the PR-merged version already.

  89. jonasw

    Dave, \o/

  90. Dave

    Ge0rG, One thing at a time, please.

  91. jonasw

    I like lists

  92. Dave

    daniel, SamWhited - #559?

  93. jonasw

    Kev, I’m not saying this is not a kick, I am saying this is a kick with a specific reason which is good to know for clients on either side of the kick

  94. jonasw

    shall I clarify that in the text?

  95. Kev

    jonasw: I think it's fine.

  96. Dave

    jonasw, It's fine.

  97. jonasw


  98. daniel

    Dave: I'm -1 on that and would like to have the general debate first on what direction we want to take the compliance suites to

  99. Dave

    daniel, I'm not sure I understand what the compliance suites have to do with #559.

  100. SamWhited

    Yah, I think I'm confused about what agenda item we're on too

  101. daniel

    Sorry. We are talking about too many topics at once

  102. jonasw

    I’ll stop my source of confusion and hop onto my train, sorry :)

  103. daniel

    Let me look up that pr

  104. Kev


  105. Ge0rG

    Somebody mixed in the future of Compliance Suite into agenda item 4.

  106. daniel

    Yes I'm +1

  107. SamWhited

    I'm on list for #559; I'm tentatively -1 to adding anything to MUC, but need time to digest the PR.

  108. Dave


  109. Dave

    That's basically all I had for the agenda. We have two items to revisit, however first I'd like to figure out our next meeting, since that's more complex than usual.

  110. SamWhited

    I'd like to propose that we do a meeting at the summit; I wanted to do it last year too but it never happened.

  111. Kev

    +2w, I suggest.

  112. Dave

    In Summits of Yore (several years ago) the Council has tried to meet in person at the Summit. Given that many of us will be travelling on the Wednesday (I am, certainly), I wondered if that was something people wanted to try?

  113. Kev

    I'd rather not, as I don't think it's a good use of the summit time, really.

  114. Kev

    Everyone not on Council is excluded (in practical terms), and we'll probably have many items to discuss.

  115. daniel

    > I'd rather not, as I don't think it's a good use of the summit time, really. +1

  116. SamWhited

    After the summit at the pub then; "in person" being the important part

  117. Ge0rG

    Feel free to meet in person at the summit, or not.

  118. daniel

    > +2w, I suggest. +1

  119. Kev

    There are things Council should discuss soon, including compliance suites, and I'm fine with doing that, but I wouldn't have a Meeting.

  120. Dave

    OK. Are we all going to the summit?

  121. Kev

    (BTW, I won't be here for +2w, but I'll happily vote on list)

  122. Ge0rG is not going.

  123. Kev

    (Or, I might not be. I'll be on holiday anyway)

  124. Dave

    Ge0rG, Boo.

  125. Ge0rG can't even promise remote attendance.

  126. SouL

    Ge0rG, sad!

  127. SamWhited

    I would specifically like it to be a meeting; I think it helps focus everyone if it's "official" in some sense and in person.

  128. Kev

    I don't think it'd be possible for me to *be* more focussed during the summit than I usually am :)

  129. Ge0rG

    Dave: I'm currently in the (early) proces of moving to a place 500km less far away from Brussels, so consider this an investment into next year's Summit.

  130. daniel

    If I remember correctly it was a pain to schedule this last year. I can't even remember if we actually managed to have a meeting

  131. Dave

    OK. We'll go for +2w, then.

  132. Ge0rG

    +2W WFM

  133. Dave

    So, back to AOB.

  134. Ge0rG

    I'd like to get a vote on 387 with #569 applied.

  135. Ge0rG

    This is Kev's feedback in https://github.com/xsf/xeps/pull/569

  136. Dave

    Ge0rG, So would I, but daniel asked for this to be after we've discussed the nature and purpose of the XEP.

  137. Ge0rG

    Dave: ah, that was the out-of-context -1 I wasn't able to associate.

  138. Dave

    SamWhited, You want to talk about XHTML-IM? I'm (still) happy to deprecate it.

  139. Kev

    I remain not sold on deprecating it, but I'm not intending to block it happening.

  140. SamWhited

    RE XHTML-IM the only concerns raised last time was that there were no alternatives. There are now at least two competing standards for doing the sort of thing XHTML-IM is normally used for, and at least one of them has one implementation in prod (Conversations) and at least one experimental one.

  141. Dave

    SamWhited, Otherwise I'll just stick it on the agenda for next meeting.

  142. SamWhited

    If there are any other concerns I'll try to address them, otherwise I think we should hold a vote again.

  143. Dave

    If I held a vote now, are people ready? Otherwise I'll just do it next meeting.

  144. Kev

    I think it'd be better for people to have a chance to revisit the discussion before voting.

  145. Kev

    I don't think having unexpected votes in meetings is conducive to either reasoned votes or getting into the desirable habit of voting immediately rather than onlist.

  146. Ge0rG

    I think XHTML-IM is not really replaced by either "alternative".

  147. Dave

    On balance, I'd prefer to hold the vote later if only to get a feel for the consensus in the community over the Summit on this one.

  148. Dave

    Kev, Yeah, I'll go along with that logic too.

  149. Kev

    So I suggest we just vote in +2w (when I will then probably have to onlist regardless, so I'm low-F)

  150. Dave

    Right, I'm doing that. SamWhited, you can spend the next two weeks convincing Ge0rG. :-)

  151. Ge0rG

    Re 387, can we please just get it published now and postpone the structural redesign for 2019?

  152. Ge0rG

    daniel: ping?

  153. Dave

    daniel, You are, I think, the only one expressing the opposing viewpoint to Ge0rG, so this is your call really.

  154. daniel

    Ge0rG: I don't want to block it all cost. But I prefer we'd talk about it next week at the summit

  155. Ge0rG

    daniel: it's a month overdue already, and next Council meeting is in +2W.

  156. daniel

    Note that I did give my +1 to the as is version

  157. Ge0rG

    daniel: and if there is feedback (and there will be!), we are talking about more iterations

  158. daniel

    If you want to publish it at all cost just publish that

  159. Ge0rG

    daniel: note that I asked for voting, now, on the version with Kev's feedback included

  160. Ge0rG

    I'm pretty sure everybody had sufficient time and opportunity to review both the current and the changed versions.

  161. daniel

    Yes I know. I was trying to give you another option if you are desperate to get it out of the door

  162. Dave

    So OK. Let's do a specific vote on XEP-387 with Kev's PR merged:

  163. Dave

    I'm +1

  164. Kev

    +1, natch

  165. Ge0rG

    +1 (as stated last week and the week before)

  166. Ge0rG

    SamWhited, daniel?

  167. Dave

    daniel, If you want to block until the discussion, that's your call. You can vote on line immediately afterward, too, since I've restarted the clock on this one.

  168. Dave

    pfft. "on list", I mean.

  169. Ge0rG

    daniel: I can't publish the pre-PR version because it's -1ed by Kev.

  170. daniel

    On list then

  171. Dave

    SamWhited, ?

  172. SamWhited

    I'll abstain with the note that I am absolutely against the president set by merging 11th hours changes and that we had a perfectly good way to move these forward before.

  173. Dave

    SamWhited, OK, thanks.

  174. Dave

    Any Other Any Other Business?

  175. Ge0rG

    I'd like to propose all council members to read Kafka's The Trial until next meeting.

  176. Dave


  177. Dave

    Anythign else?

  178. Kev


  179. Kev

    That's a lot of reading

  180. Kev

    And no, nothing from me.

  181. Dave

    Then I think we're done. Ite, meeting est - thanks all.

  182. SamWhited

    Thanks all!

  183. Ge0rG

    thanks :)

  184. SamWhited

    Ge0rG: With respect to XHTML-IM, if it helps I've found yet another XSS vulnerable client since the last time we talked. Even if the new things don't replace 100% of use cases, it feels worth deprecating just because so few people can implement it securely.

  185. Kev

    Thanks all.

  186. Ge0rG

    SamWhited: I'm not going to veto deprecation, I'm just not convinced that what we have as alternatives is a 100% replacement.

  187. SamWhited

    Ge0rG: I agree with that; it's not a 100% replacement.

  188. Dave

    Ge0rG, Also, I agree *entirely* that there aren't replacements for all the use cases of people embedding XHTML into XMPP - but I think for the limited cases XHTML-IM was intended to address, I think we have replacements for most common use cases.

  189. Ge0rG

    Dave: yes, Styling is an 80% solution, and a really awesome one (I can say that because I shamelessly stole Daniel's code)

  190. Dave

    Ge0rG, Right, exactly. I totally get Goffi et al saying they need XHTML extended, not removed, but they're using it in a blogging engine (sorta), and not IM.

  191. Ge0rG

    Maybe I can get consistent source code highlighting by using Styling with ```<language-tag>

  192. Dave

    Ge0rG, A bit niche, I feel.

  193. SamWhited

    Ge0rG: I'm still torn about whether or not it's worth having a specific "source code" tag. It does feel niche, but then again developers are probably 90% of the people using XMPP. Hard to decide if it's worth the complexity.

  194. Kev


  195. pep.

    Dave, I disagree about the niche point, goffi and edhelas would like to also allow XMPP to flourish that way, and this is not helping their case. (I'm not sure about edhelas' positions re xhtml-im)

  196. pep.

    By *that way* I mean pubsub and stuff

  197. Ge0rG

    SamWhited: I don't think that specifying the first line as "optional source code identifier" adds complexity

  198. SamWhited

    Optional is a nice way of saying "unreliable".

  199. Kev

    pep.: They're publishing source snippets in particular languages?

  200. Dave

    SamWhited, I'm cool with putting the "a content tag would go here" in the spec. Less cool with stipulating formatting for C++ and whether braces should be bold and yellow or not.

  201. Dave

    Kev, Different issue. They're dumping complex bits of XHTML into pubsub items.

  202. Kev

    SamWhited: As long as the fallback behaviour is clear and sensible, that's probably ok.

  203. SamWhited

    Dave: Oh yah, I was thinking it would just be a way to say "this is a language".

  204. Kev

    Dave: Yes, but I thought your comment about 'niche' was the source code rendering?

  205. SamWhited

    Not specific coloring or formatting

  206. Kev

    Or I completely misread the order of messages.

  207. Kev

    SamWhited: Well, mandatory then, works for me :)

  208. Ge0rG

    I don't see adding a multi-language source code parsing & coloring library into my mobile XMPP client, so having sender-side coloring via XHTML-IM was at least theoretically helpful

  209. SamWhited

    Maybe it's worth saying "text after the ``` is a meaningless tag that's not part of the pre block" and then just let people use that for whatever they want (which will probably be code highlighting)

  210. Ge0rG

    The whole tag thing starts to fall apart as soon as you try to standardize the potential values. What's C++? "cpp" or "cxx" or "c++"?

  211. SamWhited

    If clients want to make a separate spec that say to use values from pygmetized's registry, they can do that.

  212. Ge0rG

    SamWhited: I wouldn't say it's meaningless, because it's also useful for the reader to know which language it is, even if not colored

  213. Dave

    pep., I'm very much not against embedding XHTML into pubsub items. That is not what XHTML-IM was designed for, and not what it specifies either.

  214. SamWhited

    Ge0rG: fair, maybe it still shows up as a title or something.

  215. Ge0rG

    SamWhited: just say it's a language tag without strict enforcement.

  216. pep.

    Dave, ok. You'd rather see W3C XHTML in there?

  217. SamWhited

    I vaguely like the idea of just calling it a "tag" and not specifying a use for it, but I'm also worried that people would end up shoving random stuff in there as a sort of side channel API (one client thinks its a title, another thinks they can pub a JSON blob there that determines something about how it's rendered, etc.)

  218. Kev

    Countdown until someone puts CSS in it. 3...2...

  219. Dave

    pep., XHTML-IM is a small, strict subset - and one which Goffi and edhelas do not restrict themselves to. It is defined to be held within a specific element within an IM message - which Goffi and edhelas do not do.

  220. Ge0rG

    SamWhited: "a short tag intended for improved syntax highlighting of the following block"

  221. SamWhited

    Ge0rG: then someone does cpp and someone does C++ like you said and it's only use is for a particularly niche community. I'm not against it, it just gives me the funny "this is going to go horribly wrong" feeling.

  222. Dave

    pep., It's possible, in fairness, that Movim (for example) allows users to send IM messages with XHTML in, and it's possible that they're using the strict subset that XHTML-IM defines. But the use-cases they've described on-list are talking about the pubsub stuff with much richer markup.

  223. Ge0rG

    SamWhited: this is the same argument I had against all of Styling.

  224. SamWhited

    Ge0rG: what do you mean? Right now I think it's very strictly specified to avoid that

  225. Dave

    SamWhited, You don't think a common set of tags would emerge?

  226. pep.

    Dave, actually only goffi uses xhtml-im, edhelas is using atom. I named both because they are both on the pubsub front.

  227. Dave

    pep., Doesn't edhelas's Atom contain XHTML?

  228. SamWhited

    Dave: I don't, not if we don't specify a common set.

  229. Ge0rG

    SamWhited: that the syntax will inevitably lead to incorrectly styled messages for path names or other nerdy things.

  230. Kev

    I think the odds of a common list emerging organically are slim.

  231. pep.

    Dave, I don't remember, I don't use that feature myself, but that wouldn't be xhtml-im in any case

  232. Dave

    SamWhited, I don't mean that everyone will use exactly the same set. I mean that whether to use "c++" for C++ or "cpp" would probably stabilize.

  233. SamWhited

    Dave: I disagree; if some Java syntax highlighting library expects c++ and the python one expects cpp I suspect each client will just do that.

  234. Dave

    pep., That would be my point. Goffi uses tables and things which aren't in XHTML-IM, too.

  235. Ge0rG

    We could introduce our own registry of language names!

  236. SamWhited

    Ge0rG: now we're back to my ponint of "is all the additional complexity worth it?"

  237. Dave

    SamWhited, That's a possibility. But I think those libraries might well have stabilized themselves anyway.

  238. Ge0rG

    SamWhited: or maybe the Java and python libraries will be PR'ed against to support the respective other name

  239. Ge0rG

    SamWhited: </s> just in case

  240. pep.

    Dave, I meant, edhelas wouldn't call it xhtml-im in the first place (whatever is in the atom node).

  241. Dave

    pep., Ah, OK.

  242. Dave

    pep., But in any case, what they want to do - I think - is generically embed full XHTML into XMPP, particularly pubsub nodes. And that's almost exactly not the thing I think ought to be deprecated.

  243. Ge0rG

    SamWhited: I think the right level of detail is to say that it's a short language tag without further defining the expected content

  244. SamWhited

    I think that's the best idea out of the things we've just discussed, but it still feels like we're adding more stuff to the spec to cater to a niche community (although it probably is a large portion of XMPP users) and adding it in such a way that interoperability may be a problem

  245. SamWhited

    Again, I'm not against it, I just don't see a compelling reason to do it either yet and I tend to lean towards "don't add more stuff unless it's absolutely necessary"

  246. Ge0rG

    SamWhited: if we don't call it a "language tag" but a "syntax highlighting hint", it might be usable for coloring non-languages as well

  247. Ge0rG

    Though techically, I suppose, everything you want colored in a blockquote is a language

  248. Ge0rG

    SamWhited: I think that having an inconsistently used tag is a lesser interop problem than just defining it as something to be ignored

  249. pep.

    Dave, apparently 0277 recommends using XHTML-IM

  250. Ge0rG

    Let's not drift away into the "undefined behavior" vs. "implementation-defined behavior" trap of modern C.

  251. Ge0rG

    ...of modern C *compilers*.

  252. pep.


  253. Dave

    pep., Ah. So *that* needs fixing.

  254. Dave

    https://docs.google.com/spreadsheets/d/1AZ-Sna6OiRG--b-mJMKv3XXfrn3Nehm0kAtlyJvImL0/edit updated, by the way. Might add another column to track if the editor has processed the result.