danielI have two updates from the editor that weren’t on the original agenda
daniel3) Editor updates
danieljonas’, (with his editor hat on) has started the Last Call for XEP-0424 (Message Retraction) and XEP-0425 (Message Moderation)
danielwe are going to vote on that in two weeks.
jonas’not quite correct
jonas’I took the holidays into account and let the LC expire only in january
jonas’(making use of the "at least 14d" rule)
danielgood guy jonas’ thinking ahead
> 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 ;)
danielin any case we are going to vote on that after the hollidays. so make sure you are following the mailing list discussion
daniel4) Items for voting
daniela) 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!
danielhave 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
danielis this in the spirit of the CS?
danieli mean i generally agree on the change
Ge0rGI'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.
Ge0rGdaniel: I'd say that all bets are off until January 1st
Ge0rGso yes, we should make useful changes to CS'22
jonas’this is also a clear oversight, recommending a deprecated protocol makes no sense
moparisthebestI'm +1 on it
jonas’daniel, do you have +w on https://docs.google.com/spreadsheets/d/1KyQCSGAsP-nHmH1X_EQOO-MfMzqSMxgBYGRlloAhxxY/edit#gid=0 ?
danieljonas’, not yet
jonas’daniel, do you have a google account I can add?
danielshouldn’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
danielthat's something we can figure out after the meeting i guess
danielb) XEP-0060: Release version 1.23.0 (https://github.com/xsf/xeps/pull/1126)
danielprobably editorial only
danielbut doesn’t hurt to vote on it
moparisthebestis 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)
moparisthebestyea, I think the *other* MUST already exists and is fine
jonas’was that always there
jonas’well, good we passed it through here
moparisthebestI mean this makes sense and is the correct thing to do I think
moparisthebestand 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
larmaI haven't thought about this through completely, but wouldn't a SHOULD be more sensible in this case?
moparisthebestof 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
moparisthebestI 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
moparisthebestif it's not a MUST, then you MUST never submit a subset because you have no idea what it'll do
moparisthebestright, 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.
moparisthebestI 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
danieli'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.
moparisthebest2 is nicer, but if it makes existing impls non-compliant it's bad
moparisthebestI'll write these up for the list later if no one else beats me to it
moparisthebestso yea, on-list
danielsounds 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.
daniel5) Pending votes
danielnone so far
daniel6) Date of next
jonas’+1w wfm. I might not be available at +2w, though it's a normal work day for me so I should.✎
moparisthebesttentatively 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!
jonas’moparisthebest, would you post to the list if the slot stops working for you permanently and/or if you cannot attend next week?
danielGe0rG, larma ?
moparisthebestnothing from me
jonas’from me neither
danielok. i see nobody typing. This means we are done for today