XMPP Council - 2024-08-06

Reminder that we will have a council meeting in a little over an hour

\o/

I sent out an agenda just now. I realize that most of you won't be ready to vote when I sent out the agenda 40 mins before the meeting. But with a lot on our plate I think it's important to get the voting period started

looks great

Thanks for that, I think h) https://github.com/xsf/xeps/pull/1365 actually makes a normative change that we technically shouldn't make without a version bump no?

If that MUST was a SHOULD I think it'd be ok...

moparisthebest, I'm not entirely sure it *is* a normative change, but in any case it doesn't require a version bump since the wire protocol remains unchanged, surely? Other parts of the spec, such as 10.1.3's final paragraph, imply that the destroy element was always intended to be present. MUST vs SHOULD is your call; I don't think it affects whether a version bump is needed though.

I probably agree if the change is happening because that's not being done in practise then maybe SHOULD is appropriate

Can a thing following the previous version talk to a thing following the new version?

I don't see why not

But a new thing can't be written expecting a MUST if it might not happen

right. I think I agree SHOULD is more appropriate

At least old openfire didn't do this because Guus' PR links to that change 🙃

And we all know how long old openfire's stay online and not updated... 💀

If you implement new 45, you're entitled to misbehave against a server implementing the old version. That seems bad.

Well, you could say MUST include <destroy/> and include a note saying this wasn't always the case. But interestingly, this does appear to be the only casse previously where a MUC could remove you from a room without telling you why, as far as I can tell. Anyway, from a technical standpoitn a MUST is possible, I think. Politically, though, it might be undesirable.

Either way, if you introduce a version bump that would be... counterproductive, I feel.

oh yea there is no way we should introduce a version bump for this... or ever for MUC if it's remotely possible to avoid :D I was just saying that *technically* we should unless it's changed to SHOULD, so I vote to do that instead

It’s time

1) roll call

I think that version bump would be bad. I'm inclined to say 'SHOULD' with a note is the safest.

hello!

🌊

larma, dan.caseley you around?

👋

👋

Sorry, was reading back

2) Agenda bashing

nothing to bash I assume

3) Editors update

- UPDATED: XEP-0054 (vcard-temp) https://xmpp.org/extensions/xep-0054.html - UPDATED: XEP-0386 (Bind 2) https://xmpp.org/extensions/xep-0386.html - UPDATED: XEP-0478 (Stream Limits Advertisement) https://xmpp.org/extensions/xep-0478.html - Proposed XMPP Extension: Jingle Audio/Video Conferences https://xmpp.org/extensions/inbox/av_conferences.html

4) Items for voting

a) Proposed XMPP Extension: Jingle Audio/Video Conferences https://xmpp.org/extensions/inbox/av_conferences.html

on list

-1

+1, but there will be feedback on list

singpolyma, why?

it is incompatible with what's needed for most SFUs, adds unnecessary overhead, and really the whole XEP seems mostly un-needed anyway

I'm on-list, naively I don't see why it needs to MITM anything and can't just pass bytes like TURN

my main objection is the doing one call per stream instead of a multi-stream call

we already have protocol for multi-stream calls and this is what other applications and SFUs use

there is an SFU (livekit) which does two calls, one for in and one for out, but I've never seen one with one call per stream

I assume you dan.caseley are on list too?

+0. I don't hate it, but don't have the depth on SFUs and conferences to raise real insights.

moparisthebest: it can't naively forward like TURN because every endpoint will get a different set of streams with different keys. it needs special handling to do e2ee with an SFU

moparisthebest, most SFU implementations are actually passing bytes as is after SRTP-decrypting and e2ee is possible via them. DTLS-SRTP (which we typically use for encryption) is not suitable for multi-party, so it needs to be terminated somewhere if we want to send the same stream to multiple parties

larma said it better

b) XEP-0045: Additional Ban List specifications https://github.com/xsf/xeps/pull/1359

singpolyma, Is the multi-call nature needed to identify the participant, as per XEP-0298?

+1

singpolyma, I have used at least one SFU with the same structure as proposed in the XEP

+1

+1

+1 on b)

+1

larma: interesting. which one?

singpolyma, probably the same one goffi used in his prototype that formed the basis for this XEP

c) XEP-0045: Remove references to using resourceparts when banning users https://github.com/xsf/xeps/pull/1360

+1

+1

+1

+1

+1

d) XEP-0045: Improved wording of status code purpose https://github.com/xsf/xeps/pull/1361

+1

+1

+1

+1

+1

e) XEP-0045: Improve 'Service Removes Non-Member' example https://github.com/xsf/xeps/pull/1362

+1

+1

+1

+1

+1

f) XEP-0045: Clarify usage of presence stanzas when removing a non-member from a members-only room https://github.com/xsf/xeps/pull/1363

+1

+1

+1

+1

+1. Not a fan of "must be in the room" wording, but I can PR that myself if it bothers me enough

g) XEP-0045: Replace inappropriate RFC 2119 key word usage in §9.7 https://github.com/xsf/xeps/pull/1364

+1

+1

+1

+1

+1

h) XEP-0045: Presence sent to occupants of a destroyed room includes a <destroy/> https://github.com/xsf/xeps/pull/1365

tentative -1, I think the MUST MUST be SHOULD

i agree with moparisthebest

Is this a breaking change?

-0 agree with moparisthebest

same as moparisthebest

it's a bit on the safer side

to be crystal clear I'd vote +1 if that MUST was a SHOULD :D

same

I'm not against the change as is. I'd prefer more MUSTs over SHOULDs. Predictable behaviour. My problem would be down to versioning

yes

I prefer SHOULD to MUST where sensible, but here it's about compatibility expectations yes

I guess that makes me +1

Or at least a +0

dan.caseley, but you would also +1 a SHOULD?

I would

5) Pending votes

none

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1w wfm

7) AOB

I might miss next week due to kid things. Will catch up.

noaob here

dan.caseley, noted

assuming no aob then

8) Close

thank you all. see you next week

thanks all !

moparisthebest, I think the MUST could remain a MUST. The question is what happens if a new client which expects a <destroy/> doesn't see one from an old server, and I think the answer is that it still knows it's not in the room, but doesn't know why, which is exactly the state it's in now. In all other cases (old server vs old client, new server vs old client, new server vs new client) it's all fine. Also, I don't think a SHOULD means "maybe", it means the same as MUST, just with a cop-out for people who know what they're doing. There's no good reason not to do this - even people who know what they're doing ought to include the element - so the SHOULD isn't useful.

I think whether you go SHOULD or MUST, the necessary thing is the explanation that follows saying that it was not always this way, so implementations MUST cope if this is missing.

Because as the PR stands, it is illegal to send without the destroy, and therefore an entity receiving such a stanza could legitimately reject it. Including a server doing validation of protocol, if it chose.

You say "MUST (or SHOULD), but you must be prepared to accept without" and it's clear what you require a sender to do, but don't introduce potential breakage.

It wouldn't discard because it'd still be valid, no?

If the spec says "MUST have a destroy" and an entity receives without a destroy, it's entitled to reject it as invalid.

If it's a destroy, you MUST add the destroy element. If it's not a destroy though...

I see your point.

But wasn't this the only case where you didn't have a reason before?

If not, then yes, it becomes a more academic argument.

Although I think the point stands that an update to 45 shouldn't make an existing compliant implementation non-compliant without versioning/negotiation.

But you would be right that the impact would be much more limited.

wasn't the `destroy` element non-optional anyway? Two paragraphs before the text that is changed, this is written: > In order to destroy a room, the room owner MUST send an IQ set to the address of the room to be destroyed. The <iq/> stanza shall contain a <query/> element qualified by the 'http://jabber.org/protocol/muc#owner' namespace, which in turn shall contain a <destroy/> element. I introduces a MUST in the paragraph below, to avoid confusion when reading only that sentence. I don't think not using a `destroy` is valid, even prior to this change.

Isn't that IQ versus presence?

(I'm banking on the child element sent by the owner being broadcast as-is to the occupants)

(great moment for my wifi to crap out)

yeah, it is - and it's also in a different namespace - so maybe my rationale wasn't as valid.

I've got no real problem with making it a SHOULD, although it seems to me that the original intent of this always was to include at least that `destroy` child element. In my mind, I was fixing bad wording.

as an aside: shouldn't the presence ideally contain status code(s)? The unavailables that are sent in response to a service shutdown (section 11.2) do.