XMPP Council - 2020-06-03

I may be 5min late

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

Afternoon.

Hello.

🤔

here I am

1) Roll Call

Hi

everyone besides me was here already, great :)

2) Agenda Bashing

seems like no additions

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

4) Items for a Vote

none as far as I can tell

5) Outstanding Votes

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

IIRC I still have a week left, right?

jonas’, what about the 0157 change?

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

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

pep., is it ready for council?

Suuuure?

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

I mean I'm fine with doing that next week

Just curious if there's actually something blocking

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

though in this case that should first go to the list

k

Ge0rG, yes, you still have a week left

6) Date of Next

+1w wfm

Phew.

+1w wfm

+1w wfm

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

+1w wfm

:P

7) AOB

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 :)

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

Ok.

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

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

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

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

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

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

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.

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

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

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

we do have things about XEP-0050 to discuss

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

which I want to treat with priority given the CFE

Yes, sorry, let's take this OOB.

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

Deja vu :)

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

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

ISTR I did too.

GOK what it was.

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.

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

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

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

Wishlist: ELI5 this plz

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

pep.: Which 'execute'?

(Which is the issue)

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

That's remarkably coherent, thanks 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 ✏

which Kev’s PR addresses in a good way IMO

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

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

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

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

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

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

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

with my editor powers

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

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

"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"

"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)

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

I think we have a way forward until next week.

Any other AOB?

None from me.

(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)

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

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

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

either way, not in this meeting

8) Ite Meeting Est

thanks everyone

s/598/591/, sorry

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

pep., it does indeed

jonas’, Thanks!

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

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

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

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.

flow, no? why does that matter?

jonas’, 1. is also true for 598

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

flow, but in a different way

moving this to xsf@

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

love to discuss this, but my bike is waiting