XMPP Council - 2020-10-07


  1. Lance has left
  2. eta has left
  3. pprrks has joined
  4. Lance has joined
  5. neox has left
  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. adityaborikar has left
  15. adityaborikar has joined
  16. paul has joined
  17. sonny has left
  18. sonny has joined
  19. sonny has left
  20. adityaborikar has left
  21. adityaborikar has joined
  22. sonny has joined
  23. sonny has left
  24. sonny has joined
  25. sonny has left
  26. sonny has joined
  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. sonny has left
  34. sonny has joined
  35. neox has joined
  36. sonny has left
  37. Lance has left
  38. Lance has joined
  39. sonny has joined
  40. sonny has left
  41. debacle has joined
  42. sonny has joined
  43. sonny has left
  44. Lance has left
  45. Lance has joined
  46. vanitasvitae has left
  47. sonny has joined
  48. vanitasvitae has joined
  49. Lance has left
  50. sonny has left
  51. sonny has joined
  52. Lance has joined
  53. sonny has left
  54. SouL has left
  55. vaulor has left
  56. SouL has joined
  57. vaulor has joined
  58. sonny has joined
  59. adityaborikar has left
  60. adityaborikar has joined
  61. pprrks has left
  62. pprrks has joined
  63. sonny has left
  64. Lance has left
  65. pprrks has left
  66. pprrks has joined
  67. sonny has joined
  68. Ge0rG jonas’: I've pushed a new branch to gitlab, and got this on the shell: remote: To create a merge request for xep-0308, visit: remote: https://gitlab.com/ge0rg/xeps/-/merge_requests/new?merge_request%5Bsource_branch%5D=xep-0308 but the URL is a 404
  69. Ge0rG (hijacking council to not disturb xsf@)
  70. jonas’ editor@ would’ve been the right place to hijack
  71. jonas’ are you logged in?
  72. Ge0rG no I'm not. thanks. So it's just a gitlab bug where it won't ask for login
  73. Lance has joined
  74. pprrks has left
  75. pprrks has joined
  76. jonas’ yes
  77. pep. there's a sign-in link on that page
  78. pep. but that could be made more obvious
  79. Lance has left
  80. sonny has left
  81. pprrks has left
  82. Lance has joined
  83. sonny has joined
  84. pprrks has joined
  85. pprrks has left
  86. pprrks has joined
  87. Lance has left
  88. sonny has left
  89. Lance has joined
  90. sonny has joined
  91. adityaborikar has left
  92. adityaborikar has joined
  93. sonny has left
  94. Lance has left
  95. Lance has joined
  96. Lance has left
  97. sonny has joined
  98. sonny has left
  99. sonny has joined
  100. Lance has joined
  101. Lance has left
  102. Lance has joined
  103. adityaborikar has left
  104. adityaborikar has joined
  105. pprrks has left
  106. pprrks has joined
  107. Lance has left
  108. Lance has joined
  109. daniel Oh. It's Wednesday again. Time flies
  110. Lance has left
  111. adityaborikar has left
  112. adityaborikar has joined
  113. eta has joined
  114. Lance has joined
  115. Lance has left
  116. Lance has joined
  117. Lance has left
  118. jonas’ 1) Roll Call
  119. Zash !
  120. Lance has joined
  121. daniel Hi
  122. Ge0rG good morning everyone!
  123. jonas’ we have a tight agenda today, so let’s get right into it
  124. jonas’ 2) Agenda Bashing
  125. Zash dwd?
  126. dwd has joined
  127. jonas’ Zash, assuming he’ll appear
  128. dwd Hello.
  129. Zash !
  130. jonas’ I received suggestions from Ge0rG and dwd, respectively: - MR#22: XEP-0308: modernize LMC sending rules https://gitlab.com/xsf/xeps/-/merge_requests/22 - Proposed XMPP Extenison: Reactions https://xmpp.org/extensions/inbox/reactions.html
  131. jonas’ I think we can safely add that to the Items for voting section
  132. jonas’ any objections
  133. jonas’ any objections?
  134. Zash nah
  135. Ge0rG +1
  136. daniel No
  137. dwd No objections from me.
  138. jonas’ excellent
  139. jonas’ 3) Editor’s Update - Accepted Compliance Suites 2021 as XEP-0443 (pipelines still running)
  140. Ge0rG thanks very much!
  141. Ge0rG daniel: you owe us an A/V section :)
  142. jonas’ I didn’t send out the emails yet, because I fell asleep instead, but it’s there: https://xmpp.org/extensions/xep-0443.html
  143. jonas’ moving on
  144. jonas’ 4) Items for voting
  145. jonas’ 4a) Handling of XEP-0393 The LC for XEP-0393 has expired a while ago and back then Council was not able to make a clear decision about how to proceed, given the discrepancies between the XEP, the ideal world, and the real world and given the lack of community consensus. Thus, we have a four-way vote for the next meeting where we try to find a solution, based on the previous ideas floating around in the community.
  146. jonas’ soo... I’ve only made it a few more emails into the thread
  147. jonas’ personally.
  148. jonas’ Yet, I’d like to get this closed in one way or another.
  149. Zash From what I could gather, there was some agreement that it'd be fine if there was an opt-out (and maybe an opt-in). An opt-out was added.
  150. daniel My own preference is 'as is' 'move as is into informational'
  151. daniel In that order
  152. jonas’ I tend to agree with daniel.
  153. Ge0rG I also agree with daniel's order.
  154. Zash 'as is' or 'informational', no specific preference I think
  155. jonas’ I personally still don’t like this thing, but I gather that there is value in it and in the same way it was phased in, we can phase it out at some point.
  156. dwd I think I broadly agree. The consensus is certainly not smooth - lost of outlying opinion - but it's there I think.
  157. jonas’ I think we can’t put it into Informational as-is, because it defines wire format.
  158. jonas’ any other points before I start to call the votes?
  159. dwd So for Draft as is, then?
  160. jonas’ 4a i) XEP-0393: Move to Informational
  161. daniel jonas’: if we call in the order outlined in the email that order of preference is not achievable
  162. jonas’ daniel, that’s a good point
  163. jonas’ we lack a voting scheme for multiple options with preference
  164. jonas’ however, it won’t matter in this specific instance as I’m going to veto 4a i)
  165. daniel We can just flip the order
  166. dwd We do, but as all appeared to suggest we'd be OK with a advancing to Draft. So should we vote for that first and see?
  167. daniel To make it vote draft Frist
  168. jonas’ yeah, let’s do that
  169. daniel And if that fails vote for informational
  170. jonas’ /correct 4a i) XEP-0393: Accept as Draft
  171. dwd +1
  172. jonas’ +0 to accepting XEP-0393 as draft standard
  173. Ge0rG +1 to accept XEP-0393 as draft
  174. Zash +1
  175. daniel +1
  176. Zash /joke /correct +0.999994
  177. jonas’ cancelling all other votes on '393 then, because we have a way forward
  178. jonas’ thanks
  179. dwd That was so much fun it's tempting to request a CFE next week.
  180. Zash no u
  181. Ge0rG I'm sure the yaxim implementation has some significant bugs, and then also fails to implement the MUST have feature.
  182. jonas’ 4b) MR#22: XEP-0308: modernize LMC sending URL: https://gitlab.com/xsf/xeps/-/merge_requests/22 Abstract: As discussed with Kev on xsf@ MUC today, it would be good to relax the requirements on the sending client in context of MUC, Carbons and MAM. Rendered-Version: https://ge0rg.gitlab.io/-/xeps/-/jobs/777236873/artifacts/rendered-changes/xep-0308.html
  183. daniel On list. I haven't seen that in time
  184. Kev (+1 on the vote I don't get as author)
  185. Ge0rG +1
  186. Zash +1
  187. Ge0rG there is a similar issue in 0333 btw.
  188. dwd I see the change in text, but what has actually changed?
  189. jonas’ +1
  190. Ge0rG but 0333 is deferred anyway.
  191. Lance has left
  192. Lance has joined
  193. dwd Oh, 280 and 313?
  194. Kev dwd: Previously it non-normatively suggested not sending if you don't know that everyone supports it. Now it suggests sending it but suggesting you let the user know it might look like a dupe.
  195. Ge0rG dwd: the old weasel words were against sending LMC when you are not 100% sure that the recipient will understand it. The new ones are in favor
  196. Kev It's entirely in (deliberately) non-normative language, so I think it's fine.
  197. dwd OK, but it also suggests a warning thing, and also provides '280 and '313 where the client cannot possibly ever know, so it's effectively requesting clients always have an "ARE YOU SURE Y/N" after every correction. Was that the intent?
  198. Kev I don't think it suggests a confirmation.
  199. Kev Merely that the user be made aware.
  200. dwd Well, it suggests a warning. But that will be needed every time.
  201. jonas’ which would still be always
  202. jonas’ dwd, could still be a notice on the first use of corrections, since it applies always
  203. Kev Swift has always done this, I believe, with a small message at the top while you're composing an edit letting you know some people might have it appear as a dupe, unless it looks like everyone supports it.
  204. Zash Something something UI/UX considerations in XEPs etc
  205. Ge0rG That message in swift, as reported by a user, was what made me look into the issue in the first place.
  206. Kev The old test already said that it suggests letting the user know in the way that Swift does, FWIW.
  207. Kev The old text already said that it suggests letting the user know in the way that Swift does, FWIW.
  208. daniel (sorry getting real life interrupts here)
  209. Kev So the introduction of a suggested warning for the user is not new.
  210. jonas’ The key difference is that the former weasel words said that "it is expected clients do not send corrections to unsupporting clients"
  211. jonas’ while the new text says "Go ahead, but maybe warn the user
  212. jonas’ while the new text says "Go ahead, but maybe warn the user"
  213. dwd Yeah. I understand the desire here but it's basically saying "In some cases edits might not be supported. This is all cases. In those cases we suggest you warn a user." If you want to warn the user every time they use Edit, that's fine, but it's an odd phrasing.
  214. Zash I suppose you could word it more obviously as an implementation detail?
  215. Kev dwd: Fair.
  216. Ge0rG dwd: "in most IM setups"
  217. jonas’ I agree that the wording could use a bit of polishing
  218. Ge0rG dwd: I'm sure there are XMPP deployments that don't do federation and have a fixed set of clients with known features.
  219. jonas’ Ge0rG, would you take that on so that we can look at it again next week?
  220. Ge0rG jonas’: I've tried really hard to come up with a correct wording.
  221. jonas’ ok, then let’s get this solved
  222. Wojtek has joined
  223. dwd Maybe just an "In almost all cases therefore, " is enough.
  224. sonny has left
  225. Ge0rG It's probably not perfect, and I tried to keep as much of the original wording intact as possible, but I'm not sure how to make it better from where it is in the PR
  226. sonny has joined
  227. dwd Anyway, a vote - I guess +0 because I feel mean vetoing it.
  228. Ge0rG dwd: the sentence starts with "In most Instant Messaging environments"
  229. Kev As an aside if this were to lead to a material change to 308 please let me know because I'd like to take that opportunity to introduce a 'this is a fallback' payload that we could use universally.
  230. dwd But if you can reword that'd be awesome.
  231. dwd Kev, XEP-0428?
  232. jonas’ How about s/but will make/but may make/;s/In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it/In most Instant Messaging situations (due to multiple resources and recipients receiving messages which are not seen when the message is being sent, for example due to &xep0313; or multi-session nicknames in &xep0045;), it/?
  233. Kev Apologies, missed that.
  234. jonas’ How about: s/but will make/but may make/ s/In most Instant Messaging environments (particularly within a &xep0045; room, but also with a recipient having multiple clients using &xep0280; and &xep0313;) it/In most Instant Messaging situations (due to multiple resources and recipients receiving messages which are not seen when the message is being sent, for example due to &xep0313; or multi-session nicknames in &xep0045;), it/?
  235. jonas’ still not quite readable, sorry
  236. Ge0rG jonas’: +1 for "s/but will make/but may make/"
  237. jonas’ or maybe put the explanation which is currently in parenthesis in a separate paragraph, to make it less dense
  238. jonas’ Ge0rG, could you update the wording in time for the next meeting?
  239. Kev (428 doesn't quite have the semantics I was looking for explicitly called out, but yes, that would do)
  240. Ge0rG jonas’: yes
  241. jonas’ then we could move on to the next agenda item, which I expect also to take some time
  242. jonas’ Ge0rG, thanks
  243. jonas’ I retract my +1 then
  244. jonas’ 4c) Proposed XMPP Extension: Reactions URL: https://xmpp.org/extensions/inbox/reactions.html
  245. Ge0rG great, let's postpone to next week with next week's wording.
  246. daniel (sorry. I'm here for the next topic. But I'll have to catch up with history to vote on the current
  247. daniel Now former one
  248. jonas’ dwd brought this up, there was a lot of discussions, Kev retro-retracted his -1 and changed it to -0
  249. Kev Not quite.
  250. Kev My original -1 was a -1.
  251. Kev I just think Council should, at this point, take the opportunity to not be beholden to my -1.
  252. Zash +1 for experimental then
  253. jonas’ dwd brought this up, there was a lot of discussions, Kev said things about his vote
  254. Kev All my original arguments stil stand.
  255. jonas’ +1 for experimental, too
  256. daniel +1
  257. jonas’ let’s get this into experimental, let them experiment with it, and be hard about the what’s and how’s when it moves to Draft
  258. Zash This ^
  259. Kev jonas’: I am 99% confident that won't happen, and it will become immovable, FWIW :)
  260. jonas’ Kev, possible
  261. dwd We do, I think, need to solve the general problem - and I really don't want this going through to Draft without doing so - but +1.
  262. daniel Well if that's the case then it's just one more backward thing mam FC has to handle
  263. dwd jonas’, All the evidence so far is that there is no interest in finding consensus on this point.
  264. daniel It will already have to handle lmc and acks
  265. daniel *receipts
  266. Ge0rG +1 for Experimental
  267. jonas’ thanks
  268. jonas’ 5) Date of next
  269. dwd daniel, Yes, but there's no point in trying to make FC anyway if we're just going to retrofit everything.
  270. jonas’ next week *may* be tricky for me -- a kitchen will be in the process of being constructed here -- so I’m not 100% sure
  271. Lance has left
  272. jonas’ I hope it’s over by the time the council meeting happens and/or the disturbances will not prevent me from thinking that much
  273. jonas’ I’ll prepare an agenda as usual though, so I am sure that someone will be able to chair spontaneously if necessary
  274. Ge0rG +1W WFM as of now
  275. jonas’ in that sense: +1w "will work out in one way or another"
  276. Zash wfm, +1w
  277. daniel +1w wfm
  278. dwd I'll be here next week.
  279. jonas’ excellent
  280. jonas’ 6) AOB
  281. jonas’ Tedd brought up to me that we have a few XEPs stuck in Proposed state
  282. jonas’ Just as a heads up, I intend to put all of them up for reconsideration next session
  283. jonas’ XEP-0292 vCard4 Over XMPP XEP-0352 Client State Indication XEP-0353 Jingle Message Initiation XEP-0411 Bookmarks Conversion
  284. Zash :O
  285. jonas’ (after an editor-side scan if anything was missed)
  286. daniel I have an AOB
  287. jonas’ hands the mic to daniel
  288. daniel Just quickly how does council feel about CFE'ing http upload?
  289. daniel If this is turning into a longer dabate I'm happy to do it next week tho
  290. Zash Which kind is that?
  291. daniel 363
  292. Zash I mean CFE
  293. jonas’ towards final
  294. Kev CFE is to Final
  295. daniel Moving it into final
  296. jonas’ daniel, I’m all in for CFEing '363
  297. daniel I think I've never witnessed something going into final
  298. Ge0rG I don't see any issues with moving to final, but I also only have straight-forward deployments, no fancy authenticated S3 buckets
  299. daniel I'm not even sure how the process looks exactly
  300. jonas’ note that CFE is started by the editor only
  301. daniel Oh ok
  302. dwd daniel, To be honest, I'd like to get the OOB stuff moved on. '363 is broadly fine, I think, but without the other parts I worry we don't really have the experience for Final.
  303. dwd daniel, I mean, OOB if that's what people use to actually hand over the file URL to the other party.
  304. Ge0rG dwd: what would be the way forward? Replace the unstandardized OOB use with SIMS?
  305. jonas’ ok, this *is* getting out of hand
  306. Ge0rG we can continue that off-meeting
  307. dwd Ge0rG, Or define what the unstandardized OOB thing *is*.
  308. daniel Literally oob or something that replaces oob?
  309. daniel > ok, this *is* getting out of hand OK. Can we put it on next week's agenda
  310. jonas’ sure
  311. dwd daniel, I have no horse in this particular race, so I don't mind.
  312. jonas’ Any other AOB?
  313. Zash I don't recall what happened with OOB
  314. sonny has left
  315. daniel i have thoughts. but i can keep them until after the meeting
  316. dwd daniel, But if I were to have a horse in the race, it'd be one that somehow combined HTTP Upload with Jingle-FT to support other more limited environments. But that's probably wishful whimsy, and definitely not a hill for me to die on, or even climb merely to look at the view, to be honest.
  317. daniel on OOB that is
  318. jonas’ ok assuming no AOB
  319. jonas’ 8) Ite Meeting Est
  320. jonas’ Thanks for the Minutes and the "Proposed" heads up to Tedd, thanks to everyone for everything
  321. dwd jonas’, Thanks.
  322. Zash thanks
  323. jonas’ also, please move OOB etc. to xsf@
  324. Ge0rG thanks jonas’
  325. jonas’ thank you for that, too :)
  326. sonny has joined
  327. sonny has left
  328. daniel Ge0rG, I finished my move (mostly) and I will probably have more time starting next week
  329. daniel wrt compliance
  330. jonas’ \o/
  331. Ge0rG daniel: cool!
  332. adityaborikar has left
  333. sonny has joined
  334. adityaborikar has joined
  335. Lance has joined
  336. Lance has left
  337. neox has left
  338. neox has joined
  339. debacle has left
  340. Lance has joined
  341. Lance has left
  342. Lance has joined
  343. adityaborikar has left
  344. adityaborikar has joined
  345. adityaborikar has left
  346. sonny has left
  347. sonny has joined
  348. sonny has left
  349. sonny has joined
  350. debacle has joined
  351. Lance has left
  352. Wojtek has left
  353. Wojtek has joined
  354. Wojtek has left
  355. neox has left
  356. ralphm has left
  357. ralphm has joined
  358. Wojtek has joined
  359. Wojtek has left
  360. adityaborikar has joined
  361. adityaborikar has left
  362. adityaborikar has joined