I have two updates from the editor that weren’t on the original agenda
daniel
3) Editor updates
daniel
jonas’, (with his editor hat on) has started the Last Call for XEP-0424 (Message Retraction) and XEP-0425 (Message Moderation)
daniel
we are going to vote on that in two weeks.
jonas’
not quite correct
daniel
oh?
jonas’
I took the holidays into account and let the LC expire only in january
jonas’
(making use of the "at least 14d" rule)
daniel
good guy jonas’ thinking ahead
jonas’
for reference:
> This Last Call begins today and shall end at the close of business on 2022-01-04.
jonas’
I had nearly typed 2021-01-04, so I feel very proud for having spotted that before hitting push ;)
daniel
in any case we are going to vote on that after the hollidays. so make sure you are following the mailing list discussion
jonas’
</interjection>
daniel
4) Items for voting
daniel
a) XEP-0459: Replace deprecated XEP-0411 with XEP-0402 (https://github.com/xsf/xeps/pull/1129)
Ge0rG
> so make sure you are following the mailing list discussion
And please also contribute to it!
daniel
have we ever done changes to compliance suits after they became draft?
jonas’
I am generally +1, but I think there's an editorial mistake in there
daniel
is this in the spirit of the CS?
daniel
i mean i generally agree on the change
Ge0rG
I'm a bit lost with all the bookmarks formats. We recently deprecated 0411, but we also lost something in the way, right?
jonas’
daniel, I think so. our goal should be to push them to final by the beginning of 2022.
Ge0rG
daniel: I'd say that all bets are off until January 1st
Ge0rG
so yes, we should make useful changes to CS'22
daniel
fair enough
jonas’
this is also a clear oversight, recommending a deprecated protocol makes no sense
Ge0rG
+1 then
moparisthebest
I'm +1 on it
daniel
+1
jonas’
+1
larma
+1
jonas’
daniel, do you have +w on https://docs.google.com/spreadsheets/d/1KyQCSGAsP-nHmH1X_EQOO-MfMzqSMxgBYGRlloAhxxY/edit#gid=0 ?
daniel
jonas’, not yet
jonas’
daniel, do you have a google account I can add?
daniel
daniel@gultsch.de
daniel
shouldn’t we start a new one though?
jonas’
there's an empty sheet next to the "master" sheet I helpfully clobbered
jonas’
might also be worth trying to duplicate and clean out the master one :)
jonas’
either way, I see this passed unanimously
daniel
that's something we can figure out after the meeting i guess
daniel
b) XEP-0060: Release version 1.23.0 (https://github.com/xsf/xeps/pull/1126)
daniel
probably editorial only
daniel
but doesn’t hurt to vote on it
jonas’
+1
daniel
+1
moparisthebest
is it adding a MUST ?
jonas’
moparisthebest, the feature is already defined in the document
moparisthebest
> In that case, the service MUST only change the submitted configuration options.
moparisthebest
(in the case of only submitting a partial form)
moparisthebest
yea, I think the *other* MUST already exists and is fine
jonas’
oh
jonas’
was that always there
jonas’
well, good we passed it through here
moparisthebest
I mean this makes sense and is the correct thing to do I think
moparisthebest
and maybe all impls already do this and we could just let it slide...
jonas’
I think it was previously undefined
jonas’
and I seem to have seen some discussion in prosody@ which suggests that it's in fact not how all implementations work today
larma
I haven't thought about this through completely, but wouldn't a SHOULD be more sensible in this case?
moparisthebest
of the 3 changes this is the only one that gave me pause, other two are perfectly fine and just editorial
jonas’
yep, that one is definitely problematic
jonas’
I suggest we let the editor inform the author that this should go to the list first
moparisthebest
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" ?
jonas’
moparisthebest, well, the original flow is that you fetch the complete form and then submit it
moparisthebest
if it's not a MUST, then you MUST never submit a subset because you have no idea what it'll do
moparisthebest
right, so if this MUST doesn't exist, you have to keep submitting the complete form
jonas’
so you'll "never" submit a partial form (barring service updates racing with your form submission and ignoring the general inefficiency of that flow)
jonas’
so the flow in the document basically does not allow a shortcut.
moparisthebest
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
daniel
i'm withdrawing my +1 - i think this needs list discussion. to see how implementations handle that currently
jonas’
which means that we could add submitting a partial form as a feature.
Ge0rG
on-list
moparisthebest
2 is nicer, but if it makes existing impls non-compliant it's bad
moparisthebest
I'll write these up for the list later if no one else beats me to it
moparisthebest
so yea, on-list
daniel
sounds good. thank you moparisthebest
jonas’
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.
jonas’
moparisthebest, thanks.
daniel
5) Pending votes
daniel
none so far
daniel
6) Date of next
daniel
+1w wfm
jonas’
+1w wfm. I might not be available at +2w, though it's a normal work day for me so I should.✎
moparisthebest
tentatively wfm, new job and all that
jonas’
+1w wfm. I might not be available at +2w, though it's a normal work day for me so I probably will. ✏
daniel
(which then might be the last one before the holidays. but we can decide that next week)
jonas’
moparisthebest, good luck!
moparisthebest
thanks!
jonas’
moparisthebest, would you post to the list if the slot stops working for you permanently and/or if you cannot attend next week?
moparisthebest
yep!
daniel
Ge0rG, larma ?
Ge0rG
+1W WFM
larma
+1
daniel
7) AOB
me9has joined
moparisthebest
nothing from me
jonas’
from me neither
daniel
ok. i see nobody typing. This means we are done for today