XMPP Council - 2020-10-07

  1. 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

  2. Ge0rG

    (hijacking council to not disturb xsf@)

  3. jonas’

    editor@ would’ve been the right place to hijack

  4. jonas’

    are you logged in?

  5. Ge0rG

    no I'm not. thanks. So it's just a gitlab bug where it won't ask for login

  6. jonas’


  7. pep.

    there's a sign-in link on that page

  8. pep.

    but that could be made more obvious

  9. daniel

    Oh. It's Wednesday again. Time flies

  10. jonas’

    1) Roll Call

  11. Zash


  12. daniel


  13. Ge0rG

    good morning everyone!

  14. jonas’

    we have a tight agenda today, so let’s get right into it

  15. jonas’

    2) Agenda Bashing

  16. Zash


  17. jonas’

    Zash, assuming he’ll appear

  18. dwd


  19. Zash


  20. 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

  21. jonas’

    I think we can safely add that to the Items for voting section

  22. jonas’

    any objections

  23. jonas’

    any objections?

  24. Zash


  25. Ge0rG


  26. daniel


  27. dwd

    No objections from me.

  28. jonas’


  29. jonas’

    3) Editor’s Update - Accepted Compliance Suites 2021 as XEP-0443 (pipelines still running)

  30. Ge0rG

    thanks very much!

  31. Ge0rG

    daniel: you owe us an A/V section :)

  32. 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

  33. jonas’

    moving on

  34. jonas’

    4) Items for voting

  35. 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.

  36. jonas’

    soo... I’ve only made it a few more emails into the thread

  37. jonas’


  38. jonas’

    Yet, I’d like to get this closed in one way or another.

  39. 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.

  40. daniel

    My own preference is 'as is' 'move as is into informational'

  41. daniel

    In that order

  42. jonas’

    I tend to agree with daniel.

  43. Ge0rG

    I also agree with daniel's order.

  44. Zash

    'as is' or 'informational', no specific preference I think

  45. 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.

  46. dwd

    I think I broadly agree. The consensus is certainly not smooth - lost of outlying opinion - but it's there I think.

  47. jonas’

    I think we can’t put it into Informational as-is, because it defines wire format.

  48. jonas’

    any other points before I start to call the votes?

  49. dwd

    So for Draft as is, then?

  50. jonas’

    4a i) XEP-0393: Move to Informational

  51. daniel

    jonas’: if we call in the order outlined in the email that order of preference is not achievable

  52. jonas’

    daniel, that’s a good point

  53. jonas’

    we lack a voting scheme for multiple options with preference

  54. jonas’

    however, it won’t matter in this specific instance as I’m going to veto 4a i)

  55. daniel

    We can just flip the order

  56. 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?

  57. daniel

    To make it vote draft Frist

  58. jonas’

    yeah, let’s do that

  59. daniel

    And if that fails vote for informational

  60. jonas’

    /correct 4a i) XEP-0393: Accept as Draft

  61. dwd


  62. jonas’

    +0 to accepting XEP-0393 as draft standard

  63. Ge0rG

    +1 to accept XEP-0393 as draft

  64. Zash


  65. daniel


  66. Zash

    /joke /correct +0.999994

  67. jonas’

    cancelling all other votes on '393 then, because we have a way forward

  68. jonas’


  69. dwd

    That was so much fun it's tempting to request a CFE next week.

  70. Zash

    no u

  71. Ge0rG

    I'm sure the yaxim implementation has some significant bugs, and then also fails to implement the MUST have feature.

  72. 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

  73. daniel

    On list. I haven't seen that in time

  74. Kev

    (+1 on the vote I don't get as author)

  75. Ge0rG


  76. Zash


  77. Ge0rG

    there is a similar issue in 0333 btw.

  78. dwd

    I see the change in text, but what has actually changed?

  79. jonas’


  80. Ge0rG

    but 0333 is deferred anyway.

  81. dwd

    Oh, 280 and 313?

  82. 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.

  83. 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

  84. Kev

    It's entirely in (deliberately) non-normative language, so I think it's fine.

  85. 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?

  86. Kev

    I don't think it suggests a confirmation.

  87. Kev

    Merely that the user be made aware.

  88. dwd

    Well, it suggests a warning. But that will be needed every time.

  89. jonas’

    which would still be always

  90. jonas’

    dwd, could still be a notice on the first use of corrections, since it applies always

  91. 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.

  92. Zash

    Something something UI/UX considerations in XEPs etc

  93. Ge0rG

    That message in swift, as reported by a user, was what made me look into the issue in the first place.

  94. Kev

    The old test already said that it suggests letting the user know in the way that Swift does, FWIW.

  95. Kev

    The old text already said that it suggests letting the user know in the way that Swift does, FWIW.

  96. daniel

    (sorry getting real life interrupts here)

  97. Kev

    So the introduction of a suggested warning for the user is not new.

  98. jonas’

    The key difference is that the former weasel words said that "it is expected clients do not send corrections to unsupporting clients"

  99. jonas’

    while the new text says "Go ahead, but maybe warn the user

  100. jonas’

    while the new text says "Go ahead, but maybe warn the user"

  101. 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.

  102. Zash

    I suppose you could word it more obviously as an implementation detail?

  103. Kev

    dwd: Fair.

  104. Ge0rG

    dwd: "in most IM setups"

  105. jonas’

    I agree that the wording could use a bit of polishing

  106. Ge0rG

    dwd: I'm sure there are XMPP deployments that don't do federation and have a fixed set of clients with known features.

  107. jonas’

    Ge0rG, would you take that on so that we can look at it again next week?

  108. Ge0rG

    jonas’: I've tried really hard to come up with a correct wording.

  109. jonas’

    ok, then let’s get this solved

  110. dwd

    Maybe just an "In almost all cases therefore, " is enough.

  111. 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

  112. dwd

    Anyway, a vote - I guess +0 because I feel mean vetoing it.

  113. Ge0rG

    dwd: the sentence starts with "In most Instant Messaging environments"

  114. 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.

  115. dwd

    But if you can reword that'd be awesome.

  116. dwd

    Kev, XEP-0428?

  117. 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/?

  118. Kev

    Apologies, missed that.

  119. 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/?

  120. jonas’

    still not quite readable, sorry

  121. Ge0rG

    jonas’: +1 for "s/but will make/but may make/"

  122. jonas’

    or maybe put the explanation which is currently in parenthesis in a separate paragraph, to make it less dense

  123. jonas’

    Ge0rG, could you update the wording in time for the next meeting?

  124. Kev

    (428 doesn't quite have the semantics I was looking for explicitly called out, but yes, that would do)

  125. Ge0rG

    jonas’: yes

  126. jonas’

    then we could move on to the next agenda item, which I expect also to take some time

  127. jonas’

    Ge0rG, thanks

  128. jonas’

    I retract my +1 then

  129. jonas’

    4c) Proposed XMPP Extension: Reactions URL: https://xmpp.org/extensions/inbox/reactions.html

  130. Ge0rG

    great, let's postpone to next week with next week's wording.

  131. daniel

    (sorry. I'm here for the next topic. But I'll have to catch up with history to vote on the current

  132. daniel

    Now former one

  133. jonas’

    dwd brought this up, there was a lot of discussions, Kev retro-retracted his -1 and changed it to -0

  134. Kev

    Not quite.

  135. Kev

    My original -1 was a -1.

  136. Kev

    I just think Council should, at this point, take the opportunity to not be beholden to my -1.

  137. Zash

    +1 for experimental then

  138. jonas’

    dwd brought this up, there was a lot of discussions, Kev said things about his vote

  139. Kev

    All my original arguments stil stand.

  140. jonas’

    +1 for experimental, too

  141. daniel


  142. 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

  143. Zash

    This ^

  144. Kev

    jonas’: I am 99% confident that won't happen, and it will become immovable, FWIW :)

  145. jonas’

    Kev, possible

  146. 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.

  147. daniel

    Well if that's the case then it's just one more backward thing mam FC has to handle

  148. dwd

    jonas’, All the evidence so far is that there is no interest in finding consensus on this point.

  149. daniel

    It will already have to handle lmc and acks

  150. daniel


  151. Ge0rG

    +1 for Experimental

  152. jonas’


  153. jonas’

    5) Date of next

  154. dwd

    daniel, Yes, but there's no point in trying to make FC anyway if we're just going to retrofit everything.

  155. 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

  156. 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

  157. jonas’

    I’ll prepare an agenda as usual though, so I am sure that someone will be able to chair spontaneously if necessary

  158. Ge0rG

    +1W WFM as of now

  159. jonas’

    in that sense: +1w "will work out in one way or another"

  160. Zash

    wfm, +1w

  161. daniel

    +1w wfm

  162. dwd

    I'll be here next week.

  163. jonas’


  164. jonas’

    6) AOB

  165. jonas’

    Tedd brought up to me that we have a few XEPs stuck in Proposed state

  166. jonas’

    Just as a heads up, I intend to put all of them up for reconsideration next session

  167. jonas’

    XEP-0292 vCard4 Over XMPP XEP-0352 Client State Indication XEP-0353 Jingle Message Initiation XEP-0411 Bookmarks Conversion

  168. Zash


  169. jonas’

    (after an editor-side scan if anything was missed)

  170. daniel

    I have an AOB

  171. jonas’ hands the mic to daniel

  172. daniel

    Just quickly how does council feel about CFE'ing http upload?

  173. daniel

    If this is turning into a longer dabate I'm happy to do it next week tho

  174. Zash

    Which kind is that?

  175. daniel


  176. Zash

    I mean CFE

  177. jonas’

    towards final

  178. Kev

    CFE is to Final

  179. daniel

    Moving it into final

  180. jonas’

    daniel, I’m all in for CFEing '363

  181. daniel

    I think I've never witnessed something going into final

  182. Ge0rG

    I don't see any issues with moving to final, but I also only have straight-forward deployments, no fancy authenticated S3 buckets

  183. daniel

    I'm not even sure how the process looks exactly

  184. jonas’

    note that CFE is started by the editor only

  185. daniel

    Oh ok

  186. 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.

  187. dwd

    daniel, I mean, OOB if that's what people use to actually hand over the file URL to the other party.

  188. Ge0rG

    dwd: what would be the way forward? Replace the unstandardized OOB use with SIMS?

  189. jonas’

    ok, this *is* getting out of hand

  190. Ge0rG

    we can continue that off-meeting

  191. dwd

    Ge0rG, Or define what the unstandardized OOB thing *is*.

  192. daniel

    Literally oob or something that replaces oob?

  193. daniel

    > ok, this *is* getting out of hand OK. Can we put it on next week's agenda

  194. jonas’


  195. dwd

    daniel, I have no horse in this particular race, so I don't mind.

  196. jonas’

    Any other AOB?

  197. Zash

    I don't recall what happened with OOB

  198. daniel

    i have thoughts. but i can keep them until after the meeting

  199. 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.

  200. daniel

    on OOB that is

  201. jonas’

    ok assuming no AOB

  202. jonas’

    8) Ite Meeting Est

  203. jonas’

    Thanks for the Minutes and the "Proposed" heads up to Tedd, thanks to everyone for everything

  204. dwd

    jonas’, Thanks.

  205. Zash


  206. jonas’

    also, please move OOB etc. to xsf@

  207. Ge0rG

    thanks jonas’

  208. jonas’

    thank you for that, too :)

  209. daniel

    Ge0rG, I finished my move (mostly) and I will probably have more time starting next week

  210. daniel

    wrt compliance

  211. jonas’


  212. Ge0rG

    daniel: cool!