XMPP Council - 2026-08-25

Editor finally did their job so we have an agenda today. Nothing too fancy. Most of it should be fairly easy to vote on

Please pass my thanks to the editor!

it’s time

1) roll call

👋

singpolyma, goffi dan.caseley

here

Howdy!

2) Agenda bashing

we have an agenda again! i assume nothing to bash, though?!

Hello

3) editors update

• UPDATED: XEP-0066 (Out of Band Data) https://xmpp.org/extensions/xep-0066.html • UPDATED: XEP-0515 (TLS Channel-Binding Downgrade Protection) https://xmpp.org/extensions/xep-0515.html • NEW: XEP-0518 (Payment Required) https://xmpp.org/extensions/xep-0518.html

4) Items for voting

a) XEP-0143: Add author responsibility to submission process https://github.com/xsf/xeps/pull/1552

I'll wait for feeback on standard@, so next week for me.

-1 on the current variant. but good idea. see list discussion on better wording

On list. I wanna see where the thread goes.

yeah, this can probably still be improved in the wording

> You must understand and verify every part of your contribution, and ensure that material derived from other sources is properly attributed. this already sounds good to me

so seems the thread is going somewhere

+1

is this xep actually binding or linked anywhere? I'm not sure I've seen it

b) XEP-0490: Add security consideration for sender verification of PEP notifications https://github.com/xsf/xeps/pull/1554

+1 (this is mine)

+1

+1

+1

> is this xep actually binding or linked anywhere? I'm not sure I've seen it It's linked from XEP-0001, so it is part of the official and formal submission process ↺

c) XEP-0134: Add guideline against context-dependent elements https://github.com/xsf/xeps/pull/1558

i like what this is trying to achieve. i'm not sure if the wording wtih the parsers is overly specific

Seems reasonable, +1

It seems to contain and unrelated whitespace change?

i guess one could make the same argument without specific parser architecture

and I disagree with the premise

nevertheless +0

+1 I'd have liked more context, but I imagine I'd have gotten that if I'd read the whole document rather than just the diff :)

i don’t have a good alternative wording though. +1

(apologies - unscheduled server maintenance - catching up) +1 on (c)

I'm somewhat unsure why this is important. Sure, it's great to be able to reject some things early before you have the required context to do reasonable semantics checks, but also we want to be lax on what we accept in most cases anyway, so if I receive something that's technically invalid, I will still always try to make the best out of it as a receiver rather than rejecting it.

Indeed. I disagree in principle with "validating parsers" especially ones using low level tools that don't actually understand the xep.

to me it's I deserialize elements into objects. (or serialize them); the bind feature and the bind enable thing are obviously different objects that take different parameters

that’s why i agree with the premise but not the wording

Some designs allow the developer to choose a path. This PR discourages designs that prevent some choices. I don't think it's an unreasonable change.

right this basically only matters if you're blindly applying XSD or something like that

I see the wording more as hint than a formal rejection (it's "avoid") ✏

true

ok. should we reject this and ask florian to create a mailing list thread?

to see what the broader community thinks? ✏

I think that's overkill for guidance

It's not a Must

ok. in that case i'm missing votes

Sure, but also this guidance could be misunderstood

For example: should there be two different file metadata elements for two different file transfer methods if one of those require a specific metadata field present?

maybe just like with the other XEP a list discussion can yield some useful alternatives

i'm fairly sure the intent of that change is not to prevent reusing a file metadata element. but like i said maybe a list discussion yields better wording that achives the same outcome

Fair. larma, can you post your concerns to the mailing list, and see if that generates some agreeable wording?

I also don't want to claim that's the intention, but it's a way one could interpret it.

I can follow up on list, yes

d) XEP-0084: Fix example with both pubsub and HTTP source https://github.com/xsf/xeps/pull/1559

+1 i think this is almost editorial but i wanted to make sure that i/we didn’t misunderstand the xep

+1

+1

+1

+1

5) Pending votes

none

6) Date of next

+1w wfm

+1w wfm

+1w wfm

On vacation +1w 🙂

noted

7) AOB

None from me

assuming none

8) Close

thank you all. see you next week

Thanks everyone

sorry, was afk for a minute. +1w wfm

and thanks