XMPP Council - 2020-08-12

It's Council time!

1) Roll Call

I need to switch devices

one minute please

Hi

here I am

2) Agenda Bashing

sorry for the dreadful return of PR#971

any other complaints?

My coffee is cold!

… about the agenda

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

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

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

3) Editor’s Update

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

4) Items for Voting

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.

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

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

I'm staring at a diff right now .

I'm still unconvinced whether removing text adds clarity.

So.

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

or something similar, you get the gist :)

I'll read this again

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

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

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

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

daniel, hence wdiff + colordiff

+ aha | htmlpaste

:)

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

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

Sounds good

jonas’: great

Sure

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

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

Gah. Afternoon, sorry for being late.

oh great, dwd

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

(and I’d really like to hear them)

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

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

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

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

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

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?

pandoc does that

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

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

I think the colour-coding would already help ✏

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.

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

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

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

or as Ge0rG put it, indeed

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

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

that’s not my wording tho?

that’s flows wording

That wasn't jonas’

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

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

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

(and probably '369 et al. too)

whoops.

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

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

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.

what table are we talking about?

the one in your mail?

I didn’t consider that to be a table

but ok

Bullet point list. Table. It's hot.

I agree

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

I can do a PR for that, too

or maybe instead of #975

okay, either way

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

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

I am

as I said in my original email

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)

5) Date of Next

+1w?

+1w wfm

+1w wfm

+1w wfm

+1w wfm ✏

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

excellent

except the IPv4 part ✏

6) AOB

(I skipped over pending votes...)

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

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

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

*cast

ok, maybe I missed it from last week

thanks

It's hot.

any other AOB?

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

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

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

Did I curse, accidentally?

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

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

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

Heh

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

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

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

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

jonas’: thanks

AO-AO-AOB?

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

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

7) Ite Meeting Est

Thanks everyone for appearing despite the straining weather conditions

and for participating

Thanks

Thanks jonas’ and Tedd

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

+1

Text looks good.

XML error tho

Zash, thanks, fixed

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

not my choice of wording, unfortunately

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

eh, where's the diff?

oh, 971

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

There