XMPP Council - 2020-06-17

  1. stpeter has left

  2. Lance has left

  3. Lance has joined

  4. Lance has left

  5. stpeter has joined

  6. Lance has joined

  7. stpeter has left

  8. stpeter has joined

  9. debacle has left

  10. Lance has left

  11. Wojtek has left

  12. Lance has joined

  13. stpeter has left

  14. stpeter has joined

  15. stpeter has left

  16. Lance has left

  17. Tobias has joined

  18. undefined has left

  19. paul has joined

  20. undefined has joined

  21. stpeter has joined

  22. stpeter has left

  23. sonny has left

  24. sonny has joined

  25. undefined has left

  26. moparisthebest has left

  27. sonny has left

  28. sonny has joined

  29. sonny has left

  30. sonny has joined

  31. sonny has left

  32. sonny has joined

  33. undefined has joined

  34. Zash has left

  35. Zash has joined

  36. sonny has left

  37. sonny has joined

  38. undefined has left

  39. undefined has joined

  40. sonny has left

  41. sonny has joined

  42. sonny has left

  43. sonny has joined

  44. bear has left

  45. stpeter has joined

  46. vaulor has left

  47. SouL has left

  48. SouL has joined

  49. vaulor has joined

  50. susmit88 has joined

  51. bear has joined

  52. stpeter has left

  53. undefined has left

  54. undefined has joined

  55. undefined has left

  56. undefined has joined

  57. undefined has left

  58. undefined has joined

  59. undefined has left

  60. susmit88 has left

  61. susmit88 has joined

  62. undefined has joined

  63. susmit88 has left

  64. susmit88 has joined

  65. stpeter has joined

  66. stpeter has left

  67. sonny has left

  68. sonny has joined

  69. robertooo has left

  70. susmit88 has left

  71. susmit88 has joined

  72. sonny has left

  73. sonny has joined

  74. undefined has left

  75. undefined has joined

  76. robertooo has joined

  77. Kev has left

  78. stpeter has joined

  79. stpeter has left

  80. moparisthebest has joined

  81. Kev has joined

  82. undefined has left

  83. undefined has joined

  84. debacle has joined

  85. debacle has left

  86. debacle has joined

  87. undefined has left

  88. undefined has joined

  89. stpeter has joined

  90. stpeter has left

  91. undefined has left

  92. stpeter has joined

  93. Kev has left

  94. undefined has joined

  95. undefined has left

  96. undefined has joined

  97. Ge0rG

    It's this time of the week again!

  98. jonas’


  99. dwd has joined

  100. Ge0rG

    I have a hard cut in +30m due to a company-wide corona party, so let's not stretch too much today

  101. dwd

    Mexican beer?

  102. Ge0rG

    I have no idea.

  103. jonas’

    1) Roll Call

  104. daniel


  105. Ge0rG

  106. Zash


  107. undefined has left

  108. jonas’

    I’ve spotted a dwd already, so full house, excellent

  109. jonas’

    2) Agenda Bashing

  110. jonas’

    anything to modify?

  111. jonas’

    assuming no

  112. dwd

    Not from me.

  113. jonas’

    3) Editor’s Update - Calls in progress - LC for XEP-0338 (ends on 2020-06-30)

  114. jonas’

    4) Items for voting

  115. jonas’

    4a) PR#959: XEP-0156: reorganize stating XRD/JRD requirements URL: https://github.com/xsf/xeps/pull/959 Abstract: The reference to RFC 6120 was incorrect, what this really meant is RFC 6415. But instead of simply s/RFC 6120/RFC 6415/ here, I decided to reorganize stating the requirements of XRD and JRD a little.

  116. jonas’

    This PR was amended to address council feedback from last session and is on the table again.

  117. jonas’

    +1 on the PR now

  118. Zash


  119. jonas’

    I think it improves the wording and could even count as editorial at this point.

  120. dwd

    +1, though if we want to change the last bit to read "additionally", that'd be possibly clearer.

  121. jonas’

    oh, though, it makes JRD SHOULD instead of MAY

  122. Ge0rG


  123. jonas’


  124. susmit88 has left

  125. undefined has joined

  126. dwd

    Specifically, line 222 "It is possible to use an alternative JSON format..." - that always read that way but it might benefit from "additionally".

  127. daniel

    +1 on the PR

  128. dwd

    And yes, I noted that this raises JRD to a SHOULD, I assumed that was for interoperability reasons?

  129. jonas’

    I don’t think we should be nitpicking wording here on this level

  130. dwd

    jonas’, And I'm not. Just noting.

  131. jonas’


  132. jonas’

    I was tempted to reply, so I felt the need to say that instead :)

  133. jonas’

    raising the level for JRD makes sense to me in the web context, so no objections and we can move on

  134. jonas’

    4b) PR#961: XEP-0030: Specify that the disco#info feature may not be explicitly set URL: https://github.com/xsf/xeps/pull/961 Abstract: Since #715 got rejected by council, we may as well drop the requirement to specify this explicitly. See-Also: https://github.com/xsf/xeps/pull/715

  135. jonas’

    assuming my comments in the PR are addressed, I am still left to wonder what this imporoves.

  136. jonas’

    assuming my comments in the PR are addressed, I am still left to wonder what this improves.

  137. jonas’

    and I think we should set the bar for changing normative text of Final XEPs rather high.

  138. paul has left

  139. dwd

    jonas’, The problem this addresses is twofold: Firstly, it's clearly a bit weird to worry about discovering support for service discovery by first making a service discovery request to see if the response includes service discovery.

  140. jonas’

    I mean, I see that announcing disco#info is kind of pointless in a disco#info response, but I also don’t see how this fixes any real-world problem.

  141. Zash

    Sure, disco#info might be redundant to advertise. But what jonas’ said.

  142. dwd

    jonas’, Secondly, ~none of our other XEP examples include this.

  143. dwd

    jonas’, So by making this optional, it immediately means our XEPs become conformant.

  144. Zash

    dwd, examples? are not normative

  145. daniel

    is there a mailing list post or something that describes the problem that this PR is trying to address?

  146. jonas’

    I don’t see a problem with the latter. I advocated for blanket-including <!-- ... --> in disco#info examples if one is bothered by them not being complete (which I always felt to be obvious, because if every XEP had full disco#info examples we’d have much longer and more noisy texts for no gain)

  147. jonas’

    daniel, not beyond that it’s the author’s follow-up to the rejection of https://github.com/xsf/xeps/pull/715

  148. dwd

    daniel, It's trying to document reality. Seems fine by me.

  149. jonas’

    to me, it only documents reality of the examples in our documents; that it documents reality on the wire I’d like to see proven first.

  150. dwd

    That said, I'm -1 for the reasons jonas’ raiuses on the PR.

  151. paul has joined

  152. dwd

    jonas’, There was lots of discussion around this. Seems most implementations proudly return disco#info, if only to ensure there's at least one feature present.

  153. Ge0rG

    I'm on-list

  154. jonas’

    -1, unless the author can find real-world issues which are solved by this PR. Specifically, if we don’t require disco#info and then stop requiring at-lesat-one element, it might break strict validators (the existence of which I could endorse given that this is a Final document and at-least-one is a MUST) for no good reason.

  155. Zash

    -1, agree with jonas’ & dwd

  156. daniel

    yes I agree with jonas’ here as well

  157. dwd

    I could go for "disco#info MAY be elided if other features are present" quite comfortably though.

  158. jonas’

    as a sidenote, I would very much prefer us being explicit about disco#info replies specifically

  159. jonas’

    as a sidenote, I would very much prefer us being explicit about disco#info replies specifically *not* being seen as complete in XEP examples, e.g. by using <!-- ... -->.

  160. Zash


  161. jonas’

    because you could turn this the other way ’round too, if you wanted to be pedantic: if '45 does not include pubsub features, is a MUC which announces them non-comformant?

  162. dwd

    jonas’, I'd be fine with that as well.

  163. dwd

    jonas’, No, you can't.

  164. jonas’

    moving on

  165. jonas’

    dwd, as devil’s advocate, I find a way to disagree, but I don’t want to waste everyone’s time on this stupid argument of mine :)

  166. jonas’

    4c) PR#949: XEP-0157: Add status-addresses registrar entry URL: https://github.com/xsf/xeps/pull/949 See-Also: https://mail.jabber.org/pipermail/standards/2020-May/037443.html See-Also: https://mail.jabber.org/pipermail/standards/2020-June/037537.html

  167. jonas’

    We also had this one a few weeks back, but there was discussion about extending the registry without consent from '68. See the second linked mailing list thread.

  168. jonas’

    Hence, the validation stuff has been removed from the PR

  169. jonas’

    Hence, the validation stuff has been removed from the PR and converted into explicit wording, which I think is a reasonable compromise.

  170. jonas’

    This would allow us to move forward with extending '68 with validation and then amend the registry entry without breaking anything.

  171. jonas’

    so +1

  172. dwd

    +1 for this. Noting my misgivings in general about how the Registrar is operating currently.

  173. Zash


  174. jonas’

    you mean, not at all? :)

  175. jonas’

    I endorse how you rejected a PR of mine to hack into the '45 registry on that grounds (to motivate me to fix the registry), but let other’s PRs pass :)

  176. jonas’

    (no offense intended, I am glad that you don’t veto this one)

  177. jonas’

    (no offense intended or taken, I am glad that you don’t veto this one)

  178. daniel


  179. dwd

    Well, in this case the additional entry related closely to the XEP it's in.

  180. jonas’

    Ge0rG, anything from you?

  181. daniel

    pregaming for the corona party?

  182. jonas’

    assuming on-list then

  183. jonas’

    (also due to lack of chat states)

  184. jonas’

    5) Outstanding Votes - daniel and Zash are pending on PR#598 (expiring next week) AFAIK (<https://github.com/xsf/xeps/pull/598>)

  185. jonas’

    other than that, just the pending ones from Ge0rG from this session

  186. jonas’

    6) Date of Next

  187. jonas’

    +1w wfm

  188. Zash

    +1w wfm

  189. jonas’

    thooough I might have a very hard cutoff that day

  190. jonas’

    and/or might find during the week that I need a replacement

  191. jonas’

    no plans yet, but it’s a date which might cause high-priority plans to appear out of nowhere

  192. Ge0rG

    +1 for 0157

  193. Ge0rG

    Sorry, got distracted

  194. pep.


  195. jonas’

    so if someone is happy to stand in as chair in case I miss the meeting, of course with a prepared agenda, that’d be good

  196. dwd

    I can be a stand-in chair.

  197. jonas’

    thank you

  198. dwd

    If a chair *can* be a stand-in.

  199. stpeter

    Please, people, it's not safe to stand in a chair.

  200. jonas’ waves to stpeter

  201. daniel

    i’m going to be on a train for the first time in forever next wednesday. but I think i'll be able to participate from my phone

  202. jonas’

    daniel, wear your mask!

  203. jonas’

    okay, we’ll see what we can manage

  204. jonas’

    I don’t expect a lot of things to pop up anyways

  205. jonas’

    7) AOB

  206. pep.

    Yeah wearing a mask is important to participate from a phone

  207. jonas’

    anyone got any?

  208. stpeter

    BTW https://github.com/xsf/xeps/pull/905 is on my radar screen, I just need to carve out time to look at it more closely.

  209. Zash


  210. jonas’

    stpeter, excellent

  211. jonas’

    thanks for that

  212. Zash

    stpeter, while you're here, may I poke vrt vcard4? iirc it got into LC but then ???

  213. dwd

    I was wondering if we wanted to get a video call together for us, specifically *not* as a Council meeting, but as a more general chat.

  214. stpeter

    Do always feel free to poke me (hard it necessary) about PRs.

  215. jonas’

    dwd, that sounds like fun

  216. jonas’

    I hear the video call stacks around the world got a lot better in the past few months

  217. dwd

    Obviously we'll need to spend some time considering what platform to use.

  218. stpeter

    Zash: hmm, OK - as I recall, there wasn't strong interest at the time

  219. Zash

    FWIW I'll have a lot more time from next week

  220. jonas’

    dwd, please no bikeshedding on that

  221. jonas’

    if you want it to be a general chat

  222. jonas’

    if nobody objects, I’d just suggest some jitsi instance, be it the official one or the ffmuc one

  223. Ge0rG

    daniel: your optimism implies that you will be travelling abroad? ;)

  224. dwd

    Jitsi is fine by me. I'll sling some time suggestions around the Council list and see if there's interest there.

  225. stpeter

    Clearly we should create a list of all possible videoconferencing options and randomly select using the procedures in https://tools.ietf.org/html/rfc3797

  226. jonas’

    dwd, that sounds excellent, thank you

  227. jonas’

    any other AOB?

  228. stpeter

    (But seriously I'd just use Jitsi.)

  229. jonas’

    (to clarify, when I say Jitsi, I generally refer to Jitsi Meet)

  230. daniel

    Ge0rG, no. just to the other side of country

  231. jonas’

    (although I’m aware that’s incorrect)

  232. jonas’

    assuming no council-relevant AOB, so

  233. Ge0rG

    daniel: I don't think there was significant improvement of mobile network coverage in the last months ;)

  234. jonas’

    8) Ite Meeting Est

  235. jonas’

    have a splendid evening/remainder of the day everyone

  236. dwd

    Thanks jonas’!

  237. Zash

    Thanks jonas’, all

  238. Ge0rG

    thanks jonas’

  239. stpeter


  240. jonas’

    the weather here is amazing if you can repress the nagging thoughts about dryness and climate change

  241. daniel

    oh. I had honestly forgotten that this is an issue

  242. dwd

    jonas’, BTW, I was looking at Gitlab/Github mirroring; I'd not realised that Gitlab can do that automagically for you these days.

  243. jonas’

    dwd, to be honest, we’d hack that in CI jobs

  244. jonas’

    to have more control over when a mirror action happens and to have it push based and to be able to constrain the permissions

  245. Zash

    what about the locust attack in east africa?

  246. jonas’

    (using deploy keys instead of oauth permissions)

  247. Ge0rG

    speaking of which: I really liked the gitlab proposal, and I don't care much if gitlab or github is our primary venue, and I'm okay with shutting down the other one altogether after the proof-of-concept phase

  248. jonas’

    Ge0rG, thanks for the feedback

  249. jonas’

    dwd, the main issue we’re having with the gitlab migration though is the lack of the CLA bot thing... we’ll have to improvise something there, unfortunately.

  250. jonas’

    that’s really a bummer

  251. pep.

    It's curious really that there's no CLA bot

  252. pep.

    That seems to be a common thing to have CLAs (unfortunately?)

  253. jonas’

    they don’t have an "app" platform at all

  254. jonas’


  255. jonas’

    so that might be why

  256. jonas’

    or it’s simply a popularity issue

  257. pep.


  258. jonas’

    I mean there is an implementation, but you have to do AWS Lambda webscale stuff and host it yourself, which I don’t quite appreciate right now

  259. jonas’

    -> https://github.com/ScottLogic/gitlab-cla-bot/

  260. pep.

    yeah no thanks

  261. jonas’


  262. jonas’

    I mean the API should give you enough info based on that, so maybe someone from the community wants to step up and build a thing *hinthint* *nudgenudge*

  263. jonas’

    we could do a basic "hey, we don’t know you yet" comment thing in the CI with appropriate credentials, but it’d still lack any kind of interactiveness

  264. pep.

    kinda lost when it comes to searching for this specific issue

  265. pep.

    kinda lost when it comes to searching for this specific problem

  266. pep.

    re keywords

  267. jonas’

    FTR: https://gitlab.com/gitlab-org/gitlab/-/issues/15899

  268. pep.

    If we can make CI figure out if somebody has signed we can "just" make it terminate early right? We don't actually need to have any API in issues for that I guess?

  269. pep.

    Maybe it's just a flag on the issue? dunno if we can set stuff like that

  270. jonas’

    -> editor@

  271. Lance has joined

  272. Wojtek has joined

  273. undefined has left

  274. daniel has left

  275. daniel has joined

  276. undefined has joined

  277. daniel has left

  278. daniel has joined

  279. daniel has left

  280. daniel has joined

  281. undefined has left

  282. undefined has joined

  283. undefined has left

  284. undefined has joined

  285. paul has left

  286. paul has joined

  287. Wojtek has left

  288. Wojtek has joined

  289. undefined has left

  290. undefined has joined

  291. sonny has left

  292. sonny has joined

  293. sonny has left

  294. sonny has joined

  295. sonny has left

  296. sonny has joined

  297. sonny has left

  298. sonny has joined

  299. sonny has left

  300. sonny has joined

  301. paul has left

  302. paul has joined

  303. sonny has left

  304. sonny has joined

  305. bear has left

  306. Tobias has left

  307. jonas’ has left

  308. bear has joined

  309. robertooo has left

  310. robertooo has joined

  311. debacle has left

  312. paul has left

  313. kusoneko has left

  314. kusoneko has joined

  315. David has left

  316. David has joined

  317. daniel has left

  318. daniel has joined

  319. kusoneko has left

  320. kusoneko has joined

  321. David has left

  322. David has joined