XMPP Council - 2021-09-29


  1. debacle has left
  2. pprrks has left
  3. pprrks has joined
  4. SouL has joined
  5. pprrks has left
  6. Tobias has joined
  7. ChronosX88 has left
  8. ChronosX88 has joined
  9. pprrks has joined
  10. me9 has joined
  11. ChronosX88 has left
  12. ChronosX88 has joined
  13. marc0s has left
  14. marc0s has joined
  15. ChronosX88 has left
  16. ChronosX88 has joined
  17. paul has joined
  18. ChronosX88 has left
  19. ChronosX88 has joined
  20. ChronosX88 has left
  21. ChronosX88 has joined
  22. ChronosX88 has left
  23. ChronosX88 has joined
  24. ChronosX88 has left
  25. ChronosX88 has joined
  26. me9 has left
  27. marc0s has left
  28. marc0s has joined
  29. Kev has left
  30. Kev has joined
  31. Kev has left
  32. Kev has joined
  33. Kev has left
  34. Kev has joined
  35. Kev has left
  36. Kev has joined
  37. Kev has left
  38. Kev has joined
  39. Kev has left
  40. Kev has joined
  41. debacle has joined
  42. Kev has left
  43. Kev has joined
  44. Tobias has left
  45. Tobias has joined
  46. debacle has left
  47. marc0s has left
  48. marc0s has joined
  49. Kev has left
  50. Kev has joined
  51. debacle has joined
  52. ChronosX88 has left
  53. ChronosX88 has joined
  54. ChronosX88 has left
  55. ChronosX88 has joined
  56. sonny has left
  57. sonny has joined
  58. ChronosX88 has left
  59. ChronosX88 has joined
  60. ChronosX88 has left
  61. ChronosX88 has joined
  62. sonny has left
  63. sonny has joined
  64. sonny has left
  65. sonny has joined
  66. ChronosX88 has left
  67. ChronosX88 has joined
  68. Wojtek has joined
  69. ChronosX88 has left
  70. ChronosX88 has joined
  71. marc0s has left
  72. marc0s has joined
  73. alex11 has left
  74. marc0s has left
  75. marc0s has joined
  76. me9 has joined
  77. sonny has left
  78. sonny has joined
  79. sonny has left
  80. sonny has joined
  81. Wojtek has left
  82. sonny has left
  83. sonny has joined
  84. Wojtek has joined
  85. sonny has left
  86. sonny has joined
  87. jonas’ 1) Roll Call
  88. Ge0rG /o\
  89. daniel hi
  90. Zash 🙄️
  91. jonas’ the look of dread
  92. jonas’ do we get a dwd?
  93. Zash well, we?
  94. jonas’ let's se
  95. jonas’ let's see
  96. jonas’ 2) Agenda Bashing
  97. jonas’ anything?
  98. jonas’ you may voice your complaints throughout the meeting
  99. jonas’ 3) Editor's Update
  100. jonas’ nothing
  101. jonas’ 4) Items for Voting (or maybe also just discussion)
  102. jonas’ 4a) Can we talk about XEP-0313 again?
  103. Zash I guess we can
  104. Ge0rG jonas’: is that a formal vote?
  105. jonas’ I think there was some discussion last night in xsf@
  106. jonas’ Ge0rG, no.
  107. jonas’ how do we want to move forward?
  108. jonas’ there was some positive feedback to Zashes proposal on list, but Kevs is simpler
  109. jonas’ and both seem to have similar drawbacks in the end (discoverability)
  110. Ge0rG I was pressed into suppressing all but the most pressing issues I had about it.
  111. Zash I'm not going to block Kevs PR. It does have discovery and seems sane. My approach would need more thinking about discovery and seemed to add more complexity than what I could find time to think about since last week.
  112. Ge0rG I still haven't received any answers regarding how a hypothetical client in the kev usecase is supposed to query for, display or process the groupchat logs from MAM.
  113. jonas’ Ge0rG, pipe to /dev/null?
  114. jonas’ jokes aside, it seems that Kev has something specific in mind there and that it seems to work with "some clients".
  115. jonas’ It would be good to have that written down, but I don't see that as a blocking issue.
  116. Zash (I can't actually block that, but still)
  117. Ge0rG jonas’: in that case we can just remove the groupchat requirement from MAM and add a note about some servers delivering type=groupchat junk that shall be ignored
  118. jonas’ Ge0rG, well we can obviously not do that because above
  119. dwd Hello, sorry I'm late.
  120. Zash Ge0rG, so leave it at "MAY" q
  121. Zash Ge0rG, so leave it at "MAY" ?
  122. Ge0rG jonas’: well, given that the use case is a handwavy "I want to be able to search through all my seen MUC logs" that is full of corner cases, I don't agree with that assessment
  123. daniel I don't see a lot of real world problems with groupchat in mam (before we have mix). The xep needs to allow it because it makes sense for some deployments but I don't think you will experience this in the normal public ecosystem
  124. Zash I remembered something I think Ge0rG said at some point about having profiles, with corresponding disco features
  125. Ge0rG I'd rather break an experimental spec than cement something of the quality of GC1.0 into our spec.
  126. Zash Kevs PR does ... almost that
  127. daniel I haven't really been following the discussion on how to signal that because I don't really see it needs signaling in practice
  128. daniel It's still good to have it in the protocol I guess...
  129. Ge0rG daniel: well, you don't see the problems because most server implementations ignored the advice and went on with what you consider as best practice
  130. Ge0rG I'm not saying that it's wrong to ever store type=groupchat, I'm saying that it's wrong and harmful to store them by default and to return them to a standard query.
  131. Zash Ge0rG, btw, we don't actually store top level attributes of <message> stanzas (I think we said we did), but 'with' and the timestamps are derived values, from the archiving itself.
  132. Zash Ge0rG, btw, we don't actually query on* top level attributes of <message> stanzas (I think we said we did), but 'with' and the timestamps are derived values, from the archiving itself.
  133. Zash as are the ids extended mam adds
  134. jonas’ to me, the PR by Kev is sufficient
  135. jonas’ let's not make MAM another Message Archiving.
  136. MattJ Let's not indeed.
  137. Ge0rG well, it's the strictly minimal PR needed to get me away from -1.
  138. jonas’ excellent
  139. Ge0rG it's far away from a PR that makes 0313 a good spec.
  140. jonas’ I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window
  141. Zash The thing I suggested could be added later, if real need for it turns up
  142. Zash as a separate XEP even, if it makes sense
  143. Zash jonas’: Explicit lack of complaint. 🙂
  144. jonas’ \o/
  145. jonas’ moving on
  146. jonas’ 4b) XEP-0280: Advance now with the fixes applied?
  147. jonas’ I merged and pushed the changes from Ge0rG yesterday.
  148. jonas’ unless there's anything we haven't addressed yet, let's vote on Advancing to Stable
  149. jonas’ unless there's anything we haven't addressed yet && have to address before advancing, let's vote on Advancing to Stable
  150. Zash got a link to those changes?
  151. jonas’ https://github.com/xsf/xeps/pull/1105
  152. jonas’ I also extended them with a nice changelog entry
  153. Ge0rG can't we have another Last Call, for the sake of it? I'm going to miss the yearly 0280 LC otherwise.
  154. Zash Haha
  155. jonas’ Ge0rG, into your corner!
  156. Ge0rG +1 to advance XEP-0280.
  157. dwd Ge0rG, I can veto it if you like.
  158. Zash +1
  159. jonas’ +1 to aXEP-280
  160. daniel +1
  161. Ge0rG dwd: I'm interested in your rationale
  162. jonas’ +1 to advancing XEP-280, specifically NOT to dwd vetoing.
  163. dwd Ge0rG, And would like to suibscribe to my newsletter?
  164. dwd Anyway.
  165. Ge0rG After all those years of blocking 0280, this is a strange feeling.
  166. dwd Drum roll, please!
  167. jonas’ 🥁
  168. dwd +1 to advance!
  169. jonas’ 🎉
  170. ChronosX88 has left
  171. jonas’ let's quickly move on before someone changes their mind
  172. ChronosX88 has joined
  173. Ge0rG 🍾
  174. Sam 😂
  175. jonas’ 5) Pending Votes
  176. Zash ÄNTLIGEN
  177. jonas’ everyone is pending on CS-2021
  178. Ge0rG jonas’: CS-2022?
  179. jonas’ yes
  180. jonas’ that
  181. Zash CS-Source?
  182. jonas’ Zash, thanks :D
  183. dwd It's entirely possible we're pending on CS-2021 as well, mind.
  184. Zash Why not both!
  185. jonas’ let's not go there
  186. Ge0rG I've had a look at https://xmpp.org/extensions/xep-0459.html#future and I'd love to see XEP-379 and the associated XEPs become part of Advanced IM
  187. jonas’ there was some discussion about words
  188. Zash It _would_ have been nice to see more discussion
  189. dwd Anyway, I did review CS-2022 carefully, and I noticed some things I find pretty weird.
  190. jonas’ dwd, is this the right venue or should we take it to the list?
  191. dwd For one thing, we're saying that you can have a server that's "Core IM", but has no PEP, in 2022. Are there *any* servers that don't do PEP?
  192. dwd I don't think this is helped by us not actually defining anywhere what "Core" vs "Advanced" actually mean.
  193. jonas’ aren't those just words to distinguish the two levels?
  194. jonas’ but defining goals would indeed be interesting
  195. Zash Remember how there's a Core category too
  196. dwd jonas’, Sure, but what do the levels even mean?
  197. Ge0rG > This document defines XMPP application Categories based on typical use cases (Core, Web, IM, Mobile) and Levels (Core, Advanced) based on functionality in the respective category.
  198. Ge0rG Also I don't think that "Core Core" is actually a problem because you can deduplicate those words.
  199. jonas’ I don't think that the "what does advanced even mean" can be solved in a single council session, even though it seems like something council should have a stance on.
  200. dwd Ge0rG, Right, exactly. The levels are based on functionality. We decide what functionality belongs in what level based on, I dunno, functionality. Or level. I'm absolutely not blaming you for this, we should have dealt with this when we first came up with the levels.
  201. Ge0rG we could rename the levels to "Must", "Should" and "May"
  202. Zash 😀
  203. dwd Ge0rG, I did consider that, actually.
  204. dwd Anyway, I wrote a screed on this to the mailing list.
  205. jonas’ (what to do with a SHOULD in a spec which is listed in Should?! 😁)
  206. dwd But you didn't see it because I looked at the draft and binned it.
  207. dwd Mostly because we'll never fix it before the end of the year.
  208. Ge0rG dwd: there is always next year's CS.
  209. jonas’ so how do we proceed with the vote here?
  210. jonas’ does anyone want to cast this week?
  211. jonas’ otherwise I'd like to move on
  212. dwd So instead, my proposal is that we accept this and publish it, and see if we can assemble a team (a SIG, maybe?) to figure out Compliance Suite policy for the next one.
  213. dwd Hence, I'll +1 this.
  214. jonas’ dwd, that sounds like what I had in my head, so I like it ;)
  215. Ge0rG +1 with a minor note/question/AOB about promoting XEP-0379, XEP-0401 and XEP-445 into Advanced IM.
  216. Zash Observation: The diff is pretty small. https://xmpp.org/extensions/xep-0459.html#changes-2021
  217. jonas’ Ge0rG, I think you should bring that up on-list
  218. dwd I wouldn't mind our Executive Director discussing the idea of a Compliance Suite SIG with the Modern XMPP people, if he could get into contact with them.
  219. Zash s/no/yes/ on 156
  220. Zash dwd, that sounds like a grand idea
  221. Ge0rG jonas’: what about issuing LCs on the three?
  222. jonas’ Ge0rG, might be worth a shot
  223. daniel +1 to advance cs22
  224. jonas’ Ge0rG, do you think you can get ahold of the author of '401 to figure out if they are interested in taking care of the document for the LC, and if they are not, would you shepherd?
  225. jonas’ daniel, thanks
  226. jonas’ Ge0rG, heh, okay
  227. daniel Fwiw I'm against adding those xeps to the CS
  228. Ge0rG jonas’: I'm aware of two clients and one server implementation (not sure about ejabberd), and I'm pretty sure the spec is solid, as far as pre-login IQ hacks go.
  229. Ge0rG jonas’: I'm interested in shepherding 0401
  230. jonas’ Ge0rG, okay, thanks
  231. Ge0rG daniel: could you please explain?
  232. jonas’ daniel, Ge0rG, re inclusion in the CS, please take that to the list
  233. jonas’ it makes more sense to discuss this in the open
  234. jonas’ and in the corresponding thread
  235. jonas’ moving on
  236. jonas’ 6) Date of Next
  237. Zash +1 to cs2022 and let's make 2023 the best one ever
  238. jonas’ +1w wfm, unless we're in assembling-furniture-frenzy and I completely lose track of the time
  239. daniel +1w wfm
  240. jonas’ (I'll hold my vote to give Ge0rG and daniel a chance to discuss the onboarding XEPs on-list)
  241. Ge0rG +1W WFM
  242. Zash +1w wfm
  243. dwd +1WWWWWFM.
  244. Ge0rG jonas’: thanks very much!
  245. jonas’ 7) AOB
  246. jonas’ 7a) XEPs format
  247. Zash `xmllint` all the things?
  248. jonas’ there has been the occasional feedback that it'd be nice to edit XEPs in markdown. the XML we use is also a really terrible example of how to use XML for documents IMO.
  249. jonas’ I was wondering what your folks opinion on that would be, editor hat on.
  250. Zash The XML we have mixes tabs and spaces and have very long lines
  251. jonas’ with "that" being changing the official XEP language to markdown, from our custom XML schema.
  252. Zash Properly formatted and indented XML is much nicer to edit
  253. jonas’ Zash, I prefer long lines for editing.
  254. dwd I'm not mad keen on Markdown for canonical specification work, especially as it's nice to be able to extract the metadata (even if we tend not to do that right now).
  255. Ge0rG any text reflow mechanism will cause horrible PRs.
  256. Sam I have a formatter for XEPs somewhere that re-wraps lines to a configurable line length and re-tabs everything if the editors want it. I think it's left over (though it might have been rewritten since then too) from when I was an editor and we wanted to redo a few tools
  257. jonas’ because of exactly what Ge0rG said
  258. dwd I *am* keen on allowing people to write XEPs in Markdown and then convert them.
  259. jonas’ dwd, I hear you can have YAML headers on Markdown files
  260. Zash I did make those markdown←→XEP XML tools, which are in the repo since some time.
  261. jonas’ the problem with the tools is that they'll bitrot if not used regularly
  262. Ge0rG I have no strong feelings about the tooling people want to use, as long as somebody provides a word-diff tool. We used to have that and it was very useful.
  263. jonas’ I hear that word-diffing markdown is much easier than word-diffing rendered HTML
  264. Ge0rG what about word-diffing XML?
  265. jonas’ Ge0rG, noisy, but probably easier than the rendered HTML ;)
  266. Ge0rG jonas’: also is now a good time to remind you of markdown being a *superset* of HTML?
  267. daniel Wouldn't we be loosing entities?
  268. Sam I think Dante wrote a whole book about doing that
  269. jonas’ daniel, that's a good point I hadn't thought of
  270. jonas’ okay, we're overrunning anyway
  271. jonas’ any other AOB? (looking at Ge0rG )
  272. Zash That's often an argument for reStructuredText or whatsitcalled, having macros or something
  273. Ge0rG jonas’: I'm taking those to the list I think.
  274. jonas’ (reST would come with a non-terrible-hack-based PDF renderer, too.)
  275. dwd Also I do like having named anchors in XEPs for long-term reference.
  276. jonas’ Ge0rG, thanks!
  277. Ge0rG At least the XEP-0379 ones.
  278. Ge0rG not sure what else I wanted to rant about.
  279. jonas’ excellent
  280. jonas’ let's close then before you remember ;)
  281. jonas’ 8) Ite Meeting Est
  282. jonas’ thanks everyone
  283. Ge0rG good idea
  284. Ge0rG thanks jonas’
  285. daniel Thanks everyone. Thanks jonas’
  286. Zash Thanks all
  287. dwd Thanks jonas’
  288. sonny has left
  289. sonny has joined
  290. paul has left
  291. Kev > I'll instruct the editor to merge it then, unless anyone voices another complaint to me until the next merge window So, at the risk of being an arsehole, why does the Editor need an instruction to merge it? We have a process, which is that Authors have free reign to edit XEPs as they wish before Draft-as-was. In principal Council could potentially instruct the removal of an Author (although I'm not *sure* we ever codified that), but the Editor choosing not to merge a change is (almost?) unprecedented.
  292. Kev Maybe it was sensible in this case to hold off on the change, and maybe 313 is odd because of the Matt/Kev tag-team, but to be honest as the author submitting the change here the fact that it's being repeatedly suggested that I have to justify why I should be allowed to make edits to the XEP is starting to grate a little.
  293. paul has joined
  294. ChronosX88 has left
  295. ChronosX88 has joined
  296. Kev And the minutes saying that the Editor is intending merging Zash's change (which I don't think has been PRd yet) rather than mine is I *think* a typo, but didn't help my mood as I read that before reading the log here.
  297. Ge0rG Kev: I think there is this weird limbo after issuing a Last Call and before the actual advancement takes place, where changing the XEP can lead to Council Confusion
  298. Ge0rG daniel: I've written my suggestion to include 0379++ to standards@, feel please reply on list :)
  299. Ge0rG daniel: I've written my suggestion to include 0379++ to standards@, please reply on list :)
  300. Ge0rG Kev: and indeed, I agree with your assumption that it's a typo and that consensus was to merge your change
  301. Ge0rG (also given that your change fixed two of the issues I had, and Zash only provided a suggestion for fixing one of them)
  302. jonas’ Kev, uhh, you're of course right.
  303. Kev I'm not even that precious about my change, and maybe there's a better one to be made (although I don't think Zash's works very well once you follow it through to conclusion), I'm just feeling frustrated that we're not applying our usual process to the change.
  304. Zash I'm not sure what the conclusion is, it seemed to get more complicated the more I was thinking.
  305. jonas’ I (editor hat) treated this specially because '313 is currently undergoing the scrutiny of the last call process. It was a direct consequence of LC feedback from at least one council member, so to me (editor hat) it made sense to postpone applying this to keep the workload for me (editor hat) lower. Otherwise, I was running at risk of applying a change which would be modified just a week later when a council member decides to veto advancement because of disagreement.
  306. jonas’ If you think I could've handled this better, please let me know. I didn't mean to offend you in any way (by "picking" on your change). I'd have treated this the same for any change to a XEP under LC (we did the same for a change to 280, effectively)
  307. jonas’ It might've been handled differently if I wasn't editor and council chair in the same person, mind. It allows me (editor) to really quickly sync a "plan" with me (council) to get things done in the most efficient manner (for me) possible. If we had more editors, it might also have gone differently because as you say, the process is rather clear on that you could've just applied that change without any confirmation (so another editor might've done that). And it wouldn't even have been bad that way, because the load is spread. I'm currently trying to keep the load for the editor low, because it's enough work as it stands.
  308. Kev I think if our SOP is that once a LC is issued, Authors can't make changes to the XEP without Council approval, I think we should change our documents to reflect that (and *maybe* that's not a bad change), and also ensure that an LC can't happen without the Authors agreeing (I can't remember what the current state of LC issuing is, TBH).
  309. Ge0rG Kev: the author or a shepherd needs to request the LC from editor
  310. Kev I'm aware the Editor is spread thin, and I don't want to shit on the people actually doing the volunteer work for the XSF in this or other cases, to whom I'm grateful, nor make this a personal attack. I do think that if a PR that an Author is allowed to make isn't being merged, that unless we change process so they're not automatically allowed to make it, it would be useful for the Editor to explain why they would like to not merge it, and get the Author to agree. TBH, If asked "Can we hold off merging this for review so we don't have to issue two changes back to back?" on the PR, I *imagine* I'd have said 'fine'.
  311. Ge0rG Well, https://xmpp.org/extensions/xep-0001.html#proposal states that the "Editor shall formally propose *a specific revision of the XEP*" (emphasis mine), so this is not quite reflecting our current process.
  312. Zash I suppose that compounds with the general versioning troubles we've had
  313. Ge0rG §6 Discussion Process doesn't explicitly mention but kinda-sorta assumes that the author is responsible during "Experimental" and maybe "Deferred"
  314. Zash .. but not while Proposed?
  315. Ge0rG Zash: the relevant part is in §8.1: > Ultimate authority for Stable XEPs rests with the XMPP Council
  316. Ge0rG so we do not have formal restrictions on the author during Proposed.
  317. marc0s has left
  318. marc0s has joined
  319. marc0s has left
  320. marc0s has joined
  321. jonas’ Kev, feedback noted, I'll communicate that better next time. Thanks!
  322. debacle has left
  323. marc0s has left
  324. marc0s has joined
  325. debacle has joined
  326. larma has left
  327. larma has joined
  328. David has left
  329. David has joined
  330. ChronosX88 has left
  331. ChronosX88 has joined
  332. me9 has left
  333. me9 has joined
  334. marc0s has left
  335. marc0s has joined
  336. marc0s has left
  337. marc0s has joined
  338. sonny has left
  339. sonny has joined
  340. sonny has left
  341. sonny has joined
  342. SouL has left
  343. SouL has joined
  344. Wojtek has left
  345. Tobias has left
  346. me9 has left
  347. marc0s has left
  348. marc0s has joined
  349. marc0s has left
  350. marc0s has joined
  351. larma has left
  352. debacle has left
  353. SouL has left
  354. sonny has left
  355. sonny has joined