XMPP Council - 2025-06-17

I think my agenda got auto moderated on the list

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, June 17 2025 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update - UPDATED: XEP-0384 (OMEMO Encryption) https://xmpp.org/extensions/xep-0384.html - UPDATED: XEP-0388 (Extensible SASL Profile) https://xmpp.org/extensions/xep-0388.html - UPDATED: XEP-0485 (PubSub Server Information) https://xmpp.org/extensions/xep-0485.html - UPDATED: XEP-0498 (Pubsub File Sharing) https://xmpp.org/extensions/xep-0498.html - Proposed XMPP Extension: Data Policy https://xmpp.org/extensions/inbox/data_policy.html - Proposed XMPP Extension: Data Forms File Input Element https://xmpp.org/extensions/inbox/data-form-file-element.html 4) Items for voting a) XEP-0388: Fix failure example sequence https://github.com/xsf/xeps/pull/1411 b) XEP-0080: Add "regioncode" element https://github.com/xsf/xeps/pull/1442 c) Proposed XMPP Extension: Data Policy https://xmpp.org/extensions/inbox/data_policy.html d) Proposed XMPP Extension: Data Forms File Input Element https://xmpp.org/extensions/inbox/data-form-file-element.html 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/1oAHUqBdlkobDcmfQ-YRMfZHGQLMWEdOFuEUN2hdgHzs 6) Date of Next 7) AOB 8) Close

I didn't notice discussion of 4b on list, but from the peanut gallery I'd like to note that adding new elements in existing namespaces into existing 'schemas' (in the loose sense) isn't guaranteed to be backwards compatible, as there are definitely systems out there that ensure that received protocol is correct against the spec. It's clear the change couldn't be made if '80 was Final, but it's only Stable so it comes down to whether this change could be 'avoided if at all possible' (the requirement for Stable).

You mean some implementations may fail if encountering anbelment they don't know about? That seems like a bug in such implementations

If the spec says (as 80 does) "These are the elements that are allowed", then a system that validates its inputs is definitely not buggy.

Note that I'm not arguing because of M-Link behaviour here. Validating inputs is a real thing that real deployments want/need.

(Indeed, I think this change to '80 wouldn't impact M-Link or Swift)

> If the spec says (as 80 does) "These are the elements that are allowed", then a system that validates its inputs is definitely not buggy. It says "the location information itself is provided as the XML character data of the following child elements", it doesn't say "other child elements must not exist" ↺

One could argue that implementations of the current version are allowed to assume that the new element does not contain location information. I tend to believe that no harm is done if they wrongly assume so.

> It says "the location information itself is provided as the XML character data of the following child elements", it doesn't say "other child elements must not exist" Indeed. Other child elements in different namespaces would be consistent with the XMPP Way. But not additional elements in the same namespace.

Oh we have the agenda here now, cool.

Kev, 4b discussion didn't happened on list, just on xsf@ and on the issue tracker (because author where pinged). As it not mandatory elements, I thought that authors + council was enough. ✏

Let see the discussion in during council meeting. If it doesn't pass, I can make it a new XEP with separated namespace.

Daniel, BTW, I've also made a PR for registry, I'm not sure if you have seen it: https://github.com/xsf/registrar/pull/49

it’s time

1) Roll call

👋

here

singpolyma, dan.caseley you around too?

2) Agenda bashing

nothing to bash I assume

3) Editors update

I finally had some time to go through open PRs. Note there are also a bunch that are still awaiting author approval (and/or marked as draft by the author)

- UPDATED: XEP-0384 (OMEMO Encryption) https://xmpp.org/extensions/xep-0384.html - UPDATED: XEP-0388 (Extensible SASL Profile) https://xmpp.org/extensions/xep-0388.html - UPDATED: XEP-0485 (PubSub Server Information) https://xmpp.org/extensions/xep-0485.html - UPDATED: XEP-0498 (Pubsub File Sharing) https://xmpp.org/extensions/xep-0498.html - Proposed XMPP Extension: Data Policy https://xmpp.org/extensions/inbox/data_policy.html - Proposed XMPP Extension: Data Forms File Input Element https://xmpp.org/extensions/inbox/data-form-file-element.html

4) Items for voting

a) XEP-0388: Fix failure example sequence https://github.com/xsf/xeps/pull/1411

I'm wating to see where the discussion on the issue goes. So I'll be on list.

IMO it's rather the schema that's wrong. We tend to not care about ordering, so sequence feels wrong

We do care for ordering in some XEPs (like Order-By)

From the peanut gallery, using sequence where we don't mean sequence is a longstanding issue in more places than this, I believe.

(And I'd agree it's the schema rather than text at fault. Also the change breaks the comma placement to be wrong :))

yes I agree schema is wrong and since schemas are non normative ( :-) ) we can just fix the schema

so officially I guess that means i’m -1

.oO(is it an editoral fix to fix the schema?)

I would say it's editorial, especially if it's just about fixing the wrong sequence ;)

do you have a vote for us larma?

(I'd say if it's a fix, it's not editorial)

-1 as well.

Kev: but schema is non normative, so it's a non-normative fix

a.a) should daniel just fix the schema?

+1

+1

I guess I'm +1 too then.

b) XEP-0080: Add "regioncode" element https://github.com/xsf/xeps/pull/1442

given the previous discussion i'm a bit torn

I personally am +1 on this one, even after the discussion

+1 obviously (I'm the author), but I'm not sure if it's legal regarding discussion. I can make it a separated XEP if necessary.

I have certainly written consumer facing APIs that do very strict validation and complain about unknown elements (mostly so we notice typos etcs instead of just ignoring them)

so I kinda get where Kev is coming from

however we should also be pragmatic

and the original authors also seem to be on board

oh hi

I'm bad at clocks today it seems, sorry

so I guess +1

We also don't have a rule that a namespace can't be extended from another XEP, so you should never assume to have full knowledge on a namespace.

+1 on fix the schema, +0 on the example change

+1 on regioncode

c) Proposed XMPP Extension: Data Policy https://xmpp.org/extensions/inbox/data_policy.html

I'm all in for allowing strictness for attribute values when they're enum, but beyond that, it's limiting extensibility too much IMO.

+1 (I'm the author)

c) +1

I feel like this should not use data forms

(and not be in disco)

for this one, using FORM_TYPE to "bind" to a given identity seems definitely wrong to me

daniel, singpolyma: what do you suggest as alternative?

since FORM_TYPE is about standardizing fields that exist. a different field or some other strategy could be used for the desired "binding" (which doesn't even seem necessary tbh)

I think both the use of disco and data forms is totally acceptable in experimental state

data forms is a protocol in a protocol and there should be a strong reason to use it (as opposed to relatively type safe xml)

If we discover during experiments that we shouldn't use any of the two, we can still do that later.

I don't object to disco or forms per se, though there's that notion out there that unlimited numbers of extension forms shouldn't be used

data form is what is used with disco extension. It's not a new use of it.

plus i think using a dedicated syntax would give us cleaner ways to fix the gateway type situation

Meaning: I don't like data forms either and can see how disco is sub-optimal, but this is good enough for experiments

I guess that brings us back to the age old "what is experimental for" question

With author hat, not that I'm open to change, I just want to know which good alternative you suggest, PEP?

goffi, yes but either in cases where caching is highly desired (MUC, http upload size) or in cases where i know think they might have been a mistake as well: contact addresses

note that I'm open to change*

i don’t think it needs the notification mechanism of PEP. just do a custom syntax?

standardized ad hoc command ;)

It can be interesting to be notified of policy change

ToS can change, backup policy can change, etc.

maybe it can, but I guess what do we expect apps will actually do. or rather, what is your app doing right now?

plus i think the forcing anyone who wants disco#info to also retrieve policy is an anti feature. if it has to be disco do a node maybe

singpolyma: I'm planning to show a badge indicating with color + score how good a data policy is each time we write to a gateway + a detailed data policy on click.

This can be a node indeed, I was actually thinking about that earlier today.

btw I’m not necessarily saying -1. you can have your number as a stable base to work on that. but personally I don’t like that it uses disco

sounds like no current implementations and lots of possible areas to explore (disco, node, pubsub, custom) so I'm at most +0 but I guess I won't block it probably

Maybe a discussion on standard could be useful here?

I like the idea generally

(As a side note, I think it'd be handy sometimes to have a "Council's note" associated with Experimental XEPs, where concerns like this can be noted alongside the spec, so expectations (like 'I would block this going to Stable') can be set)

oh to be clear putting policy in a machine readable format on XMPP is great

but making it a custom format would be more machine readable imho

+0

I propose that I ask on standard@ for community feedback on where to put the data.

and how

larma, is this a +1 from your side?

I think once you've got an implementation it'll be more clear what is needed also in terms of caching/notification etc

As long as data is publicly and easily accessible, I'm alright with most solutions.

ok let’s move on for now. we are approaching our time limit

d) Proposed XMPP Extension: Data Forms File Input Element https://xmpp.org/extensions/inbox/data-form-file-element.html

on list. hadn’t had the time to read it yet

+1 (I'm author here too)

I read it more fully this morning. I'm against using 0446 for things vs just re-using jingle namespace as other xeps do. Also it specifies the field as (implicitly) text-single but then has a multiple boolean inside? Also it doesn't really specify how/what to submit with the form. It says to include a 0446 element for some reason, but not what the actual form value should be, etc

I do like the idea of an <accept mime="..." /> element as a data forms extension

XEP-0446 is what is used with XEP-0447 and use the elements from jingle FT

It's basically the same thing as for IM file transfer.

I mean I'm famously not a fan of 0447 for exactly this reason

Regarding `text-single`, it's the fallback, it's what is used for other data form fields extensions.

i mean we might soon reach a point where we have more 447 implementations than jingle ft implementations

why is it only a fallback though? if it were text-multiple for example and we specify that the URI goes in the <value> then the "fallback" would actually work

+1 on d) (and c as well if that was not clear enough)

Do we have more than one 447 implementation in productio?

there are 6 declared (and I still haven't done DOAP for Libervia which implements it too).

> (and c as well if that was not clear enough it wasn't :-) thank you

ok I want to wrap this up. do you have a vote singpolyma ? i mean with me and dan.caseley on list we won’t have a decision until next week anyway

as is and with no implementation +0

5) Pending votes

none

6) Date of next

+1 wfm

+1w wfm

+1w wfm

7) AOB

daniel: have you seen my PR for registry?

goffi, i have. i need to figure out how registry works

to add `gateway/activitypub`?

cool, thanks.

no other AOB from me.

ok. assuming no other AOB

8) Close

thank you all. see you next week

Thanks daniel, thanks all.

glad that we actually had things on the agenda today :-)

:)

I've restarted work on Galeway Relayed Encryption BTW, but I'll wait to add wasm directly, so it will take time as I want to test implementation first to see what is needed.