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