XMPP Council - 2024-09-17

It’s time

1) Roll call

👋

moparisthebest, dan.caseley singpolyma ?

Howdy!

👋

2) Agenda bashing

nothing to bash I assume

3) Editors update

I finally go the editor updates through that I promissed last week

* UPDATED: XEP-0133 (Service Administration) * UPDATED: XEP-0474 (SASL SCRAM Downgrade Protection) * UPDATED: XEP-0045 (Multi-User Chat) * UPDATED: XEP-0272 (Multiparty Jingle (Muji)) * NEW: XEP-0493 (OAuth Client Login) * NEW: XEP-0494 (Client Access Management)

4) Items for voting

a) XEP-0004: Empty and absent values https://github.com/xsf/xeps/pull/1387

+1

+1

+1

+1

singpolyma?

+1

b) XEP-0264: Restrict 'width' and 'height' to the 0..65535 range https://github.com/xsf/xeps/pull/1366

+1

+1

Hmm. I guess so

+0

This is incompatible with the upcoming 64k TV screens

But uh seriously +1 seems ok

While I can personally relate with a thumbnail being limited to 64k pixel in width or height, it seems like an arbitrary, unjustified restriction. +0

c) XEP-0198: Clarify server enabling SM without requested resumption https://github.com/xsf/xeps/pull/1376

+0 - I actually think the XEP is already quite clear (if you read it fully and are aware that resumption is purely optional anyway)

+1, despite the double-negative 🙂

that note might improve things slightly if you only read that one section but it may or may not also be a bit confusing because it makes things seem more complicated than they actually are

but I’m not blocking that change

Yeah I'm not sure what this note is for. This was always the case, it's just not common

The previous paragraph already says "if the server will allow .."

Implying it might not

I'm not sure this is helpful, it's roughly "resumption might not work" no?

I'm all for explicit beating implicit

The second sentence really is not easy to understand for me and I had to read it multiple times to get what they want to say. ✏

I don't think it helps and is potentially confusing but not strongly so I'll +0

I think I'm -1

It also is really not necessary, if any it is an explanation for a design decision. I would be +1 if it was just the first sentence "A server MAY enable stream management without allowing the stream to be resumed."

But stream resumption is failable, always has been, no scenario where it couldn't be?

So why call out in a seperate place that it's failable

I think I'll change my vote to -1 for now

yeah I’m wondering what exactly triggered Guus to write that note. i bet it was something like "if resumption is prevented by policy (server generally has support for it; don’t fail the enable but instead simply set resume to false

which i guess from the server devs perspective makes sense

This isn't that resumption would fail. It's that it might not be supported. But if it isn't, SM can still happen.

If Guus explains something I'm missing I can change

IMO, this is about noting that resume might be not true even if requested and the id might be missing. I could imagine implementations accidentally assume the id to always be returned if resume is set to true

but if you consider that resumption is always a negotiated feature it doesn’t really fit in that context

So the scenario he wants to cover explicitly is: Client: <enable xmlns='urn:xmpp:sm:3' resume='true'/> Server: <enabled xmlns='urn:xmpp:sm:3' resume='false'/>

Which is not obvious to be valid if you implement the XEP mostly by example and against current implementations

ok. but it seems to have been vetoed and/or would not have gotten enough +1 (with 3x0)

oh, I didn't get that at all from the change, if that was more specific then I'd be +1 I think

maybe Guus wants to improve the wording based on our feedback

or maybe we add an example `<enabled xmlns='urn:xmpp:sm:3' resume='false'/>` with the caption "server rejects resumability despite the client requesting it" or something

As a suggestion for Guus, maybe he wants to make this reply case as a seperate example below the current one

that would cover the "i only read examples folks"

yes

because again i believe the text itself is already clear

d) XEP-0313: Fix MUC archive example https://github.com/xsf/xeps/pull/1321

+1

It doesn't leave any other interpretation if you think about it, but the case of resume=false in the reply is not described at all, so there certainly is room for improvement and explicit text

+1 once that typo is fixed 🙂

(editor will apply that if the PR is otherwise accepted)

+1

Some unexplained whitespace changes. But +1

i mean technically the <enabled/> (if you assume resume defaults to false and can be omitted) is already covered by examples further above

but what ever; more examples good?!

+1

5) Pending votes

none

6) Date of Next

+1w wfm

+1w wfm

+1w wfm

+1w wfm

+1w wfm

7) AOB

No aob here

8) Close

thank you all. see you next week

Thanks daniel, thanks all

singpolyma, every XEP uses two-spaces indentation, I’ve been relentlessly fixing that for a while.

Many authors randomly use four-spaces indentation at times.

I don’t have my GitHub credentials with me, feel free to fix it for me while merging.

If it's something tooling can automatically enforce and it doesn't, the rule does not exist 🙃

.editorconfig ?