XMPP Council - 2024-08-20

Agenda for todays meeting just went out. council members please read some backlog so we can come to an agreement on #1365 in todays meeting

personal preference: > <p>Note: in older versions of this standard, the inclusion of a &lt;destroy/&gt; element was not explicitly defined to be mandatory (when no alternate location or reason are provided by the room owner). Implementations therefor cannot reliably depend on the existence of this element to identify a room destruction event.</p>

this means basically the same text we had last week but with the odd upper case removed

normative language for the normative behaviour. non normative text for the note

And then we don't have to agree or disagree on if this was clear and normative behavior to begin with. It's just an informal note

> normative language for the normative behaviour. non normative text for the note +1 nit: therefore end with e ↺

Given that it's required for interop to not rely on it, wouldn't normative s/cannot reliably/MUST NOT/ be appropriate?

Arguably not if the normative text is just a clarification and the note points to the existence of some (one?) incompatible implementation

I'm fine with that text Daniel. I'd be happy to apply that change after Council finalized discussion. I'm equally happy for you to push that change when you merge the PR - whatever you prefer.

My plan is for council to decide on a wording today and then I might as well apply that myself (instead of taking the additional round-trip of asking you, Guus, to modify and vote again next week)

Editor me wants a straight forward way to close a bunch of PRs to get them of my plate

Why do you think a new vote is needed?

In any case, I'm totally fine with that.

If it's not needed it should be an easy decision

But we didn't have a full vote yet on the current iteration of the PR

Plus I yet again changed the wording

ah ok

It’s time

1) Roll call

Hello!

singpolyma, dan.caseley larma are you around?

hello

2) Agenda bashing

nothing to bash

3) Editors updates

none

4) Items for voting

a) XEP-0045: Presence sent to occupants of a destroyed room includes a <destroy/> https://github.com/xsf/xeps/pull/1365 i’m not just yet starting voting on that particular PR instead I would like to propose the following note to be used instead > <p>Note: in older versions of this standard, the inclusion of a &lt;destroy/&gt; element was not explicitly defined to be mandatory (when no alternate location or reason are provided by the room owner). Implementations therefor cannot reliably depend on the existence of this element to identify a room destruction event.</p>

are council members happy with that? or does any one have a different proposal on how to proceed with that PR

(accept as is, reject)

s/therefor/therefore/ and then +1 for that wording

+1

+1

b) XEP-0388: Fix the XML Schema and examples https://github.com/xsf/xeps/pull/1369

(just IMO, but exact wording doesn't strictly need council to confirm, but can be done by editor as editorial)

b +1

larma, in that case I would have needed the vote for the proposed PR anyway

+1

b) +1

moparisthebest?

+1

c) XEP-0045: Explicitly use bare JIDs when operating on affiliations https://github.com/xsf/xeps/pull/1371

+1

c +1

+1

+1

d) XEP-0045: Allow non-owners to retrieve owner and admin lists in non-anonymous rooms https://github.com/xsf/xeps/pull/1372

d +1

+1

+1

e) XEP-0402: Specify what clients should do if autojoin='0' in bookmark notifications https://github.com/xsf/xeps/pull/1373

this is more than a 'clarification'.

personally i’m leaning towards +1

it seems like the logical opposite to what is explained a sentence prior (join when modified to true)

and i certainly implemented it that way

I disagree

I don't like this speccing UX stuff

I understand the xep already sort of does in one place

How would I signal that I want to join a room only for this session?

By joining and setting autojoin=0

I agree that most clients don't want this these days, but it still is a perfectly valid usecase

i guess whether or not you consider that UX depends on how you look at that xep entirely

i always understood that xep to describe an automated functioniality

you can like or dislike that xep

but that modification feels in line with the rest

I think it's fine, nothing stops a client from allowing you to manually join a room with autojoin 0

So I'm +1

i think nothing in that xep says that you should even display bookmarks as bookmarks

Heh, it has indeed evolved into a secondary roster of sorts :)

(fwiw I don't think this is mandating UX, it explains the intent behind values, and the explanation was missing here)

so as far as that xep is concerned it's describing only an automated way to sync what mucs you are joined

anyway do you want to vote or should I ask the author to bring this to the list first?

I'm +0

Imho not specifying what 0 means is a hole in the spec that needs addressed regardless Since I don't have a better suggestion for addressing it, +1

yes. otherwise it feels weird that it mandates that you leave when the bookmark is deleted and when an autojoin is added; but doesn’t say what to do when the autojoin is removed

i understand singpolyma point in so far that mandating something in the first place (leave on delete) is a bit weird but that ship has sailed

Leave iff you joined due to autojoin=1 ?

(in fact in Conversations I only implemented the leave on delete fairly recently after taking a long time to think about it)

anyway let me know how you want to proceed; reject, vote on list; open up more list discussion singpolyma

we are running up on our 30min time limit

> yes. otherwise it feels weird that it mandates that you leave when the bookmark is deleted and when an autojoin is added; but doesn’t say what to do when the autojoin is removed I agree this is weird. What is weird IMO is that it says to leave when deleted :P ↺

xep is stable so I guess there's no way to fix that anyway right?

I might like it more if it was non-normative instead of a strong SHOULD

I certainly would be fine with a MAY 😉

Sorry, I was in a work thing I couldn't escape. I'm +1 to everything so far. The fact that clients are already treating autojoin=0 this way pushes towards hyperaccuracy of standards, trailing the implementation (perhaps improperly), but if most implementations aren't opinionated on it currently, it seems harmless.

fwiw the other join leave instructions are SHOULD too

> fwiw the other join leave instructions are SHOULD too yes 😞 ↺

Ok. I guess I'll go -0 I don't like it, but the xep is already like this and already stable

I don’t know it seems you simply don’t like the (purpose) of the XEP.

IMO instructing clients to join if autojoin=1 makes sense, because well, the flag means to automatically join. But autojoin=0 does not mean autoleave=1 😉

Can always make a new XEP (:

it's all SHOULD; so a client wide 'ignore autojoin flags' expert settings can ignore the shoulds

> IMO instructing clients to join if autojoin=1 makes sense, because well, the flag means to automatically join. But autojoin=0 does not mean autoleave=1 😉 larma: what does it mean ↺

for a 'i want different behaviour on my phone' experience

Not join automatically, but maybe manually

dan.caseley, a-e yes?

Yes please

inb4 autojoin=complicated client query language expression

I’m going +1 on 402 too. which means the XEP passes (with 3 +1 and 2 +0)

5) Pending votes

none

6) Date of Next

+1w wfm

+1w wfm (but i'll propably be on a hard 30min time limit; shorter is better)

+1w wfm

+1w wfm

I'll be on holiday (again), but will possibly join all the same

7) AOB

Thanks Guus for working so hard to polish the rough edges off MUC <3

(no other aob here)

8) Close

thank you all. see you next week

It's utterly self serving, but you are welcome

Guus: fair but you could have just noted it yourself and not bothered with PRs or discussions so we all appreciate it :)

Thanks all!