XMPP Council - 2021-12-08

Almost that time

almost!

It's time

Good morning everyone

1) Roll call

👋

Hello

good morning

do we get a larma?

yes 🙂

2) Agenda bashing

I have two updates from the editor that weren’t on the original agenda

3) Editor updates

jonas’, (with his editor hat on) has started the Last Call for XEP-0424 (Message Retraction) and XEP-0425 (Message Moderation)

we are going to vote on that in two weeks.

not quite correct

oh?

I took the holidays into account and let the LC expire only in january

(making use of the "at least 14d" rule)

good guy jonas’ thinking ahead

for reference: > This Last Call begins today and shall end at the close of business on 2022-01-04.

I had nearly typed 2021-01-04, so I feel very proud for having spotted that before hitting push ;)

in any case we are going to vote on that after the hollidays. so make sure you are following the mailing list discussion

</interjection>

4) Items for voting

a) XEP-0459: Replace deprecated XEP-0411 with XEP-0402 (https://github.com/xsf/xeps/pull/1129)

> so make sure you are following the mailing list discussion And please also contribute to it!

have we ever done changes to compliance suits after they became draft?

I am generally +1, but I think there's an editorial mistake in there

is this in the spirit of the CS?

i mean i generally agree on the change

I'm a bit lost with all the bookmarks formats. We recently deprecated 0411, but we also lost something in the way, right?

daniel, I think so. our goal should be to push them to final by the beginning of 2022.

daniel: I'd say that all bets are off until January 1st

so yes, we should make useful changes to CS'22

fair enough

this is also a clear oversight, recommending a deprecated protocol makes no sense

+1 then

I'm +1 on it

+1

+1

+1

daniel, do you have +w on https://docs.google.com/spreadsheets/d/1KyQCSGAsP-nHmH1X_EQOO-MfMzqSMxgBYGRlloAhxxY/edit#gid=0 ?

jonas’, not yet

daniel, do you have a google account I can add?

daniel@gultsch.de

shouldn’t we start a new one though?

there's an empty sheet next to the "master" sheet I helpfully clobbered

might also be worth trying to duplicate and clean out the master one :)

either way, I see this passed unanimously

that's something we can figure out after the meeting i guess

b) XEP-0060: Release version 1.23.0 (https://github.com/xsf/xeps/pull/1126)

probably editorial only

but doesn’t hurt to vote on it

+1

+1

is it adding a MUST ?

moparisthebest, the feature is already defined in the document

> In that case, the service MUST only change the submitted configuration options.

(in the case of only submitting a partial form)

yea, I think the *other* MUST already exists and is fine

oh

was that always there

well, good we passed it through here

I mean this makes sense and is the correct thing to do I think

and maybe all impls already do this and we could just let it slide...

I think it was previously undefined

and I seem to have seen some discussion in prosody@ which suggests that it's in fact not how all implementations work today

I haven't thought about this through completely, but wouldn't a SHOULD be more sensible in this case?

of the 3 changes this is the only one that gave me pause, other two are perfectly fine and just editorial

yep, that one is definitely problematic

I suggest we let the editor inform the author that this should go to the list first

I tend to think this has to be a MUST or MUST NOT or something, otherwise what use is "you can't tell what this will do" ?

moparisthebest, well, the original flow is that you fetch the complete form and then submit it

if it's not a MUST, then you MUST never submit a subset because you have no idea what it'll do

right, so if this MUST doesn't exist, you have to keep submitting the complete form

so you'll "never" submit a partial form (barring service updates racing with your form submission and ignoring the general inefficiency of that flow)

so the flow in the document basically does not allow a shortcut.

I think only one of these 2 things make sense: 1. you MUST always fetch+submit a full form, no ambiguity as to what happens 2. if you MAY submit a subset, then the service MUST only change the submitted ones, and not the others

i'm withdrawing my +1 - i think this needs list discussion. to see how implementations handle that currently

which means that we could add submitting a partial form as a feature.

on-list

2 is nicer, but if it makes existing impls non-compliant it's bad

I'll write these up for the list later if no one else beats me to it

so yea, on-list

sounds good. thank you moparisthebest

moparisthebest, as we do not know all implementations and it removes a subset of the space of "implementation defined", it will make some implementation non-compliant probably.

moparisthebest, thanks.

5) Pending votes

none so far

6) Date of next

+1w wfm

tentatively wfm, new job and all that

+1w wfm. I might not be available at +2w, though it's a normal work day for me so I probably will. ✏

(which then might be the last one before the holidays. but we can decide that next week)

moparisthebest, good luck!

thanks!

moparisthebest, would you post to the list if the slot stops working for you permanently and/or if you cannot attend next week?

yep!

Ge0rG, larma ?

+1W WFM

+1

7) AOB

nothing from me

from me neither

ok. i see nobody typing. This means we are done for today

8) Close

Thanks everyone

thanks daniel

thanks daniel

thanks all, till next time

thanks daniel 🙂