XMPP Council - 2020-06-03


  1. jonas’

    I may be 5min late

  2. Ge0rG

    I'm semi here and might have to disappear suddenly.

  3. dwd

    Afternoon.

  4. Zash

    Hello.

  5. Ge0rG

    🤔

  6. jonas’

    here I am

  7. jonas’

    1) Roll Call

  8. daniel

    Hi

  9. jonas’

    everyone besides me was here already, great :)

  10. jonas’

    2) Agenda Bashing

  11. jonas’

    seems like no additions

  12. jonas’

    3) Editor’s Update - Calls in Progress - CFE for XEP-0050 (ends at 2020-06-09)

  13. jonas’

    4) Items for a Vote

  14. jonas’

    none as far as I can tell

  15. jonas’

    5) Outstanding Votes

  16. jonas’

    Ge0rG, you have some, do you want to discuss any of them?

  17. Ge0rG

    IIRC I still have a week left, right?

  18. pep.

    jonas’, what about the 0157 change?

  19. pep.

    Are we waiting on something else to put the new revision to a vote?

  20. Ge0rG

    I wasn't able to catch up with the ML, sorry

  21. jonas’

    pep., is it ready for council?

  22. pep.

    Suuuure?

  23. jonas’

    ah, I think we should indeed quickly bring the thing about adding validation stuff to the registry to the list

  24. pep.

    I mean I'm fine with doing that next week

  25. pep.

    Just curious if there's actually something blocking

  26. jonas’

    pep., next time, please send such suggestions in reply to the agenda

  27. jonas’

    though in this case that should first go to the list

  28. pep.

    k

  29. jonas’

    Ge0rG, yes, you still have a week left

  30. jonas’

    6) Date of Next

  31. jonas’

    +1w wfm

  32. Ge0rG

    Phew.

  33. Zash

    +1w wfm

  34. daniel

    +1w wfm

  35. dwd

    Can we do +6 days, 23 hours, and 55 minutes? ;-)

  36. Ge0rG

    +1w wfm

  37. jonas’

    :P

  38. jonas’

    7) AOB

  39. Kev

    Did my comments about 393 get through to the list? I would have expected *some* response unless they didn't get through, or I'm being shunned :)

  40. jonas’

    Kev, they did, I read them, and I don’t think I had anything to add

  41. Kev

    Ok.

  42. dwd

    Kev, I think I did mention them, didn't I, in my response to larma?

  43. jonas’

    though I have to admit that I’m kind of fatigued about this discussion

  44. Ge0rG &

  45. Kev

    dwd: Oh. My bad. I missed that somehow.

  46. SamWhited

    Kev: I think I lost them in the wall of emails; reading now, sorry.

  47. dwd

    Kev, I meant to, anyway. I did quite like the suggestion of a flag to indicate "I know what I'm doing so you can strip the markup".

  48. dwd

    Kev, Though that *really* needs a formal grammar, IMHO.

  49. Kev

    SamWhited: The short version is that if you include an opt-in then it signals to a client using a screen reader (for example) that it can strip the markup so it can be usefully accessible. Without changing other semantics.

  50. SamWhited

    Kev: I see, that is a good point. I'll have to think about how that interacts with things, but that's a fairly convincing argument at first blush

  51. Kev

    Which doesn't solve all cases (e.g. clients that do something like 393 without saying so), but significantly helps accessibility for some cases.

  52. jonas’

    since the '393 discussion on-list is going quite vividly, I’d prefer to move this out of this meeting

  53. jonas’

    we do have things about XEP-0050 to discuss

  54. dwd

    Overall, though, I found larma's treatise on it very useful indeed.

  55. jonas’

    which I want to treat with priority given the CFE

  56. SamWhited

    Yes, sorry, let's take this OOB.

  57. jonas’

    7a) The 'execute' Problem of XEP-0050

  58. Kev

    Deja vu :)

  59. jonas’

    but it’s useful that Kev is around, since he was involved in the previous iteration of this :)

  60. dwd

    Kev, ISTR you had a concrete suggestion of what to do here?

  61. Kev

    ISTR I did too.

  62. Kev

    GOK what it was.

  63. jonas’

    Tedd nicely quoted from the minutes from some time, which I’ll quote here: 3) XEP-0050 'execute' Issue … Kev explains that it's possible to have an illegal state because 'execute' is overloaded in weird ways - there is an execute action, and an execute attribute for setting a default action, but the execute-attribute default action is not the execute action, which may well be invalid. … Dave attempts to clarify that the default for the execute action is 'complete', unless other actions are specified whereby the default is 'next' which may not even be present - Kev confirms. Kev mentions PR #598 (https://github.com/xsf/xeps/pull/598) as his attempt to address the issue by unifying the execute attribute and action into one, and that everyone should consider carefully whether this solution will break anything. Kev explains further that currently if execute is set to 'complete' and the execute command is run, it's actually 'next' that's run; and if there is no 'next' action defined, that's obviously a problem. Dave is justifiably mystified. Dave suggests an alternative solution might be to deprecate the execute action; Kev thinks this could be a better solution. Peter utters from the shadows that he recently found his marked-up paper copy of XEP-0050 from several years ago - Kev asks whether it fixes this issue - alas, they are mostly editorial notes. Dave repeats his suggestion of deprecating the execute action, on the basis of unexpected behaviour; Sam agrees this seems like a good solution as multiple people have been confused in a similar way.

  64. jonas’

    So looking at the PR, I (editor hat) closed this because it was for the previous council period and nobody cared enough to process it

  65. jonas’

    I suggest we re-open the PR and vote on it next week

  66. jonas’

    In addition, I’d like to ask Kev (as the owner of the PR) to add a bit of wording around deprecation of the execute action to avoid any pitfalls

  67. Zash

    Wishlist: ELI5 this plz

  68. pep.

    Zash, 'execute' has weird semantics. burn it!

  69. Kev

    pep.: Which 'execute'?

  70. Kev

    (Which is the issue)

  71. jonas’

    Zash, - action='execute' is always allowed - if the @execute is not set, action='execute' is equivalent to action='next' - if the form specifies a list of actions which does not include next -> undefined behaviour

  72. pep.

    Kev, I see. Sorry that wasn't helpful :)

  73. Kev

    That's remarkably coherent, thanks jonas’.

  74. jonas’

    Zash, - action='execute' is always allowed - if the @execute is not set, action='execute' is equivalent to action='next' - if the form specifies a list of allowed actions which does not include next -> undefined behaviour

  75. jonas’

    which Kev’s PR addresses in a good way IMO

  76. jonas’

    I’d just like to have another paragraph somewhere which hints people at not using 'execute' if it can be avoided

  77. Kev

    I would need to re-read it to be sure, and to see how it's different to Dave's suggestion.

  78. jonas’

    Kev, I think it’s orthogonal. Your PR states explicitly that no @execute + actions without next = invalid.

  79. Kev

    I do remember that this is one of those "Everything is broken, you can't fix it without something being broken" situations.

  80. jonas’

    I’d like to have a bit of wording in there which also states "Don’t 'execute', it’s weird"

  81. Kev

    I think the odds of me providing that wording at the moment are vanishingly small, I'm afraid.

  82. jonas’

    Kev, good to know, I’ll hijack that PR then

  83. jonas’

    with my editor powers

  84. jonas’

    and then I’ll re-propose it for next week’s council

  85. flow

    I wonder why #598 was closed in the first place?

  86. pep.

    "jonas’> So looking at the PR, I (editor hat) closed this because it was for the previous council period and nobody cared enough to process it"

  87. Kev

    "So looking at the PR, I (editor hat) closed this because it was for the previous council period and nobody cared enough to process it" (Jonas)

  88. jonas’

    flow, it was dormant, and I (Editor hat) did a cleanup of stale PRs

  89. jonas’

    I think we have a way forward until next week.

  90. jonas’

    Any other AOB?

  91. dwd

    None from me.

  92. pep.

    (Maybe the best would have been to bring it back to council, but I don't think that was a wrong decision anyway, and it's done now :x)

  93. flow

    I'd like to point out that there was an alternative suggestion by me in PR #591

  94. flow

    I think 598 and 591 are the two options to move forward

  95. jonas’

    > council vetoed a few months ago and discussed rewording to make the intention clear. (from #598)

  96. jonas’

    either way, not in this meeting

  97. jonas’

    8) Ite Meeting Est

  98. jonas’

    thanks everyone

  99. jonas’

    s/598/591/, sorry

  100. pep.

    hmm, digging through issues: https://lab.louiz.org/poezio/slixmpp/issues/3432 this looks oddly similar?

  101. flow

    pep., it does indeed

  102. dwd

    jonas’, Thanks!

  103. Zash

    The only action I can see anything in Prosody care about is 'cancel'

  104. pep.

    I have a MR still waiting for this, but I wasn't sure if it was correct in the first place

  105. flow

    Zash, does prosody initiate a lot of ad-hoc commands?

  106. jonas’

    flow, at a first glance, 591 has multiple problems: - It defines previously undefined behaviour, making implementations which were previously neutral non-compliant - It does not solve the issue for when neither next nor complete are allowed.

  107. Zash

    flow, no? why does that matter?

  108. flow

    jonas’, 1. is also true for 598

  109. flow

    2. I think it states that execute is mapped to next in that case

  110. jonas’

    flow, but in a different way

  111. jonas’

    moving this to xsf@

  112. flow

    I think what Kev said is right, that is one of those "Everything is broken, you can't fix it without something being broken" situations

  113. flow

    love to discuss this, but my bike is waiting