XMPP Council - 2020-08-12


  1. Ge0rG

    It's Council time!

  2. jonas’

    1) Roll Call

  3. jonas’ is here

  4. Zash here is

  5. Ge0rG

  6. jonas’

    I need to switch devices

  7. jonas’

    one minute please

  8. daniel

    Hi

  9. jonas’

    here I am

  10. jonas’

    2) Agenda Bashing

  11. jonas’

    sorry for the dreadful return of PR#971

  12. jonas’

    any other complaints?

  13. Zash

    My coffee is cold!

  14. jonas’

    … about the agenda

  15. jonas’

    nice, now the work laptop is playing a snippet of metal in a very tight loop

  16. jonas’

    trying suspend-then-hibernate wasn’t a good plan

  17. jonas’

    ok, with that disturbance out of the way...

  18. jonas’

    3) Editor’s Update

  19. jonas’

    - XEP-0045 v1.33.0 which removes 307 status code from service-caused kicks (as opposed to moderation-caused kicks)

  20. jonas’

    4) Items for Voting

  21. jonas’

    4a) Discuss whether PR#971 was rejected on false premises Sorry for this one. Flow brought up -- correctly -- that type="cancel" is special and we should discuss real quick if that changes anything for the folks who vetoed.

  22. jonas’

    since XEP-0004 states: > a data form of type "cancel" SHOULD NOT contain any <field/> elements. I think some of the arguments in my original email regarding this topic may be invalid

  23. jonas’

    since others based their vote on those arguments, please reconsider

  24. jonas’

    and let me know if we should re-vote on this one

  25. Zash

    I'm staring at a diff right now .

  26. Ge0rG

    I'm still unconvinced whether removing text adds clarity.

  27. Zash

    So.

  28. jonas’

    trivial example of where removing text adds clarity: > The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types. vs. > "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W and X.

  29. jonas’

    trivial example of where removing text adds clarity: > The form type "foo" has properties X. The properties Y and Z are only on form type "bar", which also has property X. Property W is found on both "foo" and "baz" types. vs. > "foo" has Property X and W, "bar" has property X, Y and Z, and "baz" has property W only.

  30. jonas’

    or something similar, you get the gist :)

  31. daniel

    I'll read this again

  32. daniel

    The diff format with extremely long lines also makes this super hard to read

  33. Ge0rG

    jonas’: so the answer to your question is probably: we should re-vote #971

  34. jonas’

    re-writing my email from back then, I arrive at: Let me break this change down using the word diff (attached: ab.wdiff, pipe it through colordiff(1) for best viewing). Before: - type="form": @type SHOULD, absent implies "text-single" - type="submit": @type MAY, absent assumes available context(*) - type="result": @type MAY, absent undefined - type="error": SHOULD NOT have any fields, @type MAY After: - type="form": @type SHOULD, absent implies "text-single" - type="submit", type="result": @type MAY, absent assumes available context(*) - type="error": SHOULD NOT have any fields, @type MAY (*): It is assumed that the recipient of the form has enough context to infer the @type value. Bad design IMO, but we’re stuck with that. So while the PR reduces the amount of text, it introduces undefined behaviour for @type="error", which I don’t endorse.

  35. jonas’

    re-writing my email from back then, I arrive at: Let me break this change down using the word diff (attached: ab.wdiff, pipe it through colordiff(1) for best viewing). Before: - type="form": @type SHOULD, absent implies "text-single" - type="submit": @type MAY, absent assumes available context(*) - type="result": @type MAY, absent undefined - type="error": SHOULD NOT have any fields, @type undefined After: - type="form": @type SHOULD, absent implies "text-single" - type="submit", type="result": @type MAY, absent assumes available context(*) - type="error": SHOULD NOT have any fields, @type MAY (*): It is assumed that the recipient of the form has enough context to infer the @type value. Bad design IMO, but we’re stuck with that. So while the PR reduces the amount of text, it introduces undefined behaviour for @type="error", which I don’t endorse.

  36. jonas’

    and I think I prefer that a lot and would also suggest to re-vote

  37. jonas’

    daniel, hence wdiff + colordiff

  38. Zash

    + aha | htmlpaste

  39. jonas’

    :)

  40. jonas’

    I’m still in favour of my patch though, because that handles the case where an entity violates the SHOULD NOT for type="error" and clearly spells out what’s going on

  41. jonas’

    I guess I’ll propose my patch as separate PR and then we can vote on both?

  42. daniel

    Sounds good

  43. Ge0rG

    jonas’: great

  44. Zash

    Sure

  45. Ge0rG

    and maybe Zash can provide a rendered html-diff of it ;)

  46. jonas’

    https://github.com/xsf/xeps/pull/975

  47. dwd

    Gah. Afternoon, sorry for being late.

  48. jonas’

    oh great, dwd

  49. jonas’

    I suppose you’ll have strong opinions regarding how we should handle Process here

  50. jonas’

    (and I’d really like to hear them)

  51. Zash

    https://cerdale.zash.se/upload/ZYq7Ie4XUavFzq0k/pr971.html

  52. Ge0rG

    jonas’: is there really Process for bringing up the same PR again?

  53. jonas’

    Ge0rG, probably not written down, but dwd still might have a valuable opinion on that :)

  54. Ge0rG

    Zash: it is HTML, but it's not HTML.

  55. jonas’

    Zash, those \" make it harder to read :/

  56. dwd

    PRs are nothing but a convenient way to give things to Council, I don';t think there's anything preventing us using the same one twice is there?

  57. Zash

    pandoc does that

  58. jonas’

    dwd, no, it’s about re-voting on the same thing after council pretty clearly vetoed it before

  59. jonas’

    Zash, can you do the diff on the xml instead of whatever pandoc did there?

  60. jonas’

    I think the colour-coding would already hep

  61. jonas’

    I think the colour-coding would already help

  62. dwd

    Ah. So there's nothing that prevents us doing so, but unless new things have come to light I feel a little concerned about doing that.

  63. jonas’

    (hoping that none of us has red-green-weakness)

  64. Ge0rG

    dwd: new things like the realization that the first voting Member was wrong, and the other ones just copy&pasted the rationale?

  65. jonas’

    dwd, I expected as much. Do you think that new things did indeed come to light based on what I wrote earlier (in the agenda announcement and above, I shall quote from above): since XEP-0004 states: > a data form of type "cancel" SHOULD NOT contain any <field/> elements. I think some of the arguments in my original email regarding this topic may be invalid since others based their vote on those arguments, please reconsider

  66. jonas’

    or as Ge0rG put it, indeed

  67. Zash

    jonas’: Main difference is extra noise and lack of line breaks in paragraphs.

  68. Ge0rG

    jonas’: I really like your wording as displayed by Zash's colored "html" version

  69. jonas’

    that’s not my wording tho?

  70. jonas’

    that’s flows wording

  71. Zash

    That wasn't jonas’

  72. dwd

    Ge0rG, Well, there's a good argument to avoid "me too" veto votes, of course. :-)

  73. Ge0rG

    dwd: yes, I'm guilty of that. But the rationale that was provided really sounded convincing back then!

  74. jonas’

    it’s easy to construct convincing-sounding rationales for '4, '45 and '60.

  75. jonas’

    (and probably '369 et al. too)

  76. Ge0rG

    whoops.

  77. jonas’

    though I’ll clearly state that this was not my intention and I simply wasn’t aware of the type="cancel" specialcasing

  78. Ge0rG

    So I really like flow's wording then. Can we also get a pr975.html, please? Zash?

  79. dwd

    I like the table. ISTR I was on-list because I was confused about what the wording used to say and what it now says, which at the very least suggests that the wording needs improvement.

  80. jonas’

    what table are we talking about?

  81. Ge0rG

    the one in your mail?

  82. jonas’

    I didn’t consider that to be a table

  83. jonas’

    but ok

  84. dwd

    Bullet point list. Table. It's hot.

  85. jonas’

    I agree

  86. Zash

    ^C^V that into the XEP and call it a day?©

  87. jonas’

    I can do a PR for that, too

  88. jonas’

    or maybe instead of #975

  89. jonas’

    okay, either way

  90. jonas’

    we’re close to the end of the meeting and everyone is confused

  91. dwd

    But if I understand correctly, we're happy about the intent in flow's PR, just not so much about the wording?

  92. jonas’

    I am

  93. jonas’

    as I said in my original email

  94. jonas’

    I take that we should re-vote on PR#971 and/or PR#975 next week. Please read carefully everyone, I’ll update PR#975 with a more major reformatting after this meeting (taking the suggestion to pull my "table" from the email into the document)

  95. jonas’

    5) Date of Next

  96. Zash

    +1w?

  97. jonas’

    +1w wfm

  98. Zash

    +1w wfm

  99. daniel

    +1w wfm

  100. Ge0rG

    +1W WFM

  101. Ge0rG

    +1w wfm

  102. dwd

    +1. Having (a) moved my XMPP server to AWS off the machine that was failing, and (b) moved DNS to a machine with IPv4, I might even be able to join properly.

  103. jonas’

    excellent

  104. jonas’

    except the IPv4 port

  105. jonas’

    except the IPv4 part

  106. jonas’

    6) AOB

  107. jonas’

    (I skipped over pending votes...)

  108. jonas’

    Ge0rG, wanna vote on the SASL-EXTERNAL one? it expires today.

  109. jonas’

    https://github.com/xsf/xeps/pull/963

  110. Ge0rG

    I'm pretty sure I already +1ed SASL-EXTERNAL, but consider it being casted now.

  111. Ge0rG

    *cast

  112. jonas’

    ok, maybe I missed it from last week

  113. jonas’

    thanks

  114. Ge0rG

    It's hot.

  115. jonas’

    any other AOB?

  116. Ge0rG

    I sent a mail to standards@ re MUC-PMs vs. Direct Messages

  117. jonas’

    it contained several words I find highly complex and I am out of my safe operating parameters

  118. Ge0rG

    There was one response so far. I'd love to see more.

  119. jonas’

    it contained several words I find highly complex and I am outside my safe operating parameters

  120. Ge0rG

    Did I curse, accidentally?

  121. dwd

    I would like to second Ge0rG's observation that it is hot.

  122. jonas’

    Ge0rG, no, but you said nasty words like "MUC-PM", "Carbons", and "MAM"

  123. Ge0rG

    or are those words "RECOMMENDED" and "SHOULD NOT"?

  124. Zash

    Heh

  125. Ge0rG

    jonas’: I was just setting the stage. The mail is mostly harmless.

  126. jonas’

    https://share.dreckshal.de/dpm/Ct5F9khjRIzTuqrGSBM_Nr0URuHpdsbwWdzOdWXhW48.png

  127. jonas’

    Ge0rG, thanks for the hint, I’ll take a look and see that I can reply soon-ish

  128. jonas’

    if you don’t see an email from me in that thread by the end of the week, feel free to poke.

  129. Ge0rG

    jonas’: thanks

  130. jonas’

    AO-AO-AOB?

  131. jonas’

    (real quick, because we’re past the time)

  132. jonas’

    no typing notification and no previous mention, taking that as a no

  133. jonas’

    7) Ite Meeting Est

  134. jonas’

    Thanks everyone for appearing despite the straining weather conditions

  135. jonas’

    and for participating

  136. Zash

    Thanks

  137. Ge0rG

    Thanks jonas’ and Tedd

  138. jonas’

    I updated PR#975: https://github.com/xsf/xeps/pull/975

  139. Ge0rG

    +1

  140. Zash

    Text looks good.

  141. Zash

    XML error tho

  142. jonas’

    Zash, thanks, fixed

  143. Zash

    > the recieving entity can infer the 'type' attribute value from context often, but not allways

  144. jonas’

    not my choice of wording, unfortunately

  145. Zash

    https://cerdale.zash.se/upload/rbYit4kCAuY1LCQu/pr971.html

  146. Zash

    eh, where's the diff?

  147. Zash

    oh, 971

  148. Zash

    https://cerdale.zash.se/upload/wWubXvCY6TocdW5Z/pr975.html

  149. Zash

    There