XMPP Council - 2025-10-15

I'm checking XEP-0485 for the last call, and I see that: ```xml <field var='serverinfo-pubsub-node'> <value>xmpp:pubsub.shakespeare.lit?;node=serverinfo</value> </field> ``` Should not the clark notation be used here, as requested by XEP-0068? The var should be `{urn:xmpp:serverinfo:0}pubsub-node` IMO. It's not blocking for the last call as this can be discussed in this context.

goffi, doesn't that apply (only) to field-names _not_ standardized by the XSF?

I don't think so. it's useful to find where the data is coming from: if not namespaced, I know that the field is defined in the XEP defining `urn:xmpp:serverinfo:0`. The clark notation is really useful to find which spec to look for.

The way I understand it, we have to use clark notation as long as we add a field not in the original spec defining the data form.

But this can be discussed during in the last call process on standard@, this is not blocking for last call.

To discover where field names come from, if they are XSF-defined, we have the Registrar.

goffi: it's in a data form that is namespace?!

Not saying we MUST NOT use Clark notation, but given the amount of implementations that are already out there, I wonder if the benefit of having that identifying bit in there would outweigh the compatibility issue.

By namespaced I mean it has its own data form with a form type

Daniel, not sure to understand well you question, but XEP-0485 add a field in an existing data form already namespaced (from XEP-0157).

Guus, I understand your concern about existing implementation, but this is to be expected with an experimental spec, specially if we move to stable.

goffi: ah sorry. Never mind then

> To discover where field names come from, if they are XSF-defined, we have the Registrar. I don't think that there is any registry mapping each field to corresponding XEP. It's the namespaces which are linked. ↺

Another point, in Privacy Considerations, I see "The mere presence of an applicable pub-sub node MUST NOT be used for Service Discovery purposes, as under common service configuration, non-administrative users are allowed to create such nodes.". This could be solved by moving the node to server's own PEP.

Where no normal user can create a node.

(I'm not sure if all PEP implementation support that though).

Daniel, I've now checked everything, I'm +1 on everything from yesterday agenda.

Wondering if No-Reply JIDs would not be better on a per-message basis, but I see that it has already been discussed in design considerations. Anyway, not a blocker for experimental.

Goffi, I won't argue that if we want to apply that Clark-notation change, this is the best time to do (when moving the XEP to the next level of standardization), but I still don't see much of a benefit.

Goffi: I don't see a reason why individual users should want to announce this feature in a PEP node. The feature doesn't really apply to individual users, but to the server as a whole.

Are you seeing a different use-case for this? That _would_ be interesting.

Guus, I'm not talking about individual PEP, but about server's own PEP (with the jid example.org, not user@example.org).

Ah. I've never considered that a server-domain could have its own PEP. :D

I mean nothing prevent the server from having a PEP service for itself.

The idea is not from me, it was mentioned in original version of https://xmpp.org/extensions/xep-0455.html by mathieui, I actually did implement server PEP for this use case in Libervia Pubsub.

But it totally make sense that the server can have a PEP itself. It's easy to add for implementations if it's not already possible, and it make so many use case cleaner or easier (like avoiding a node to be create by user in the XEP-0485 case). ✏

But it totally make sense that the server can have a PEP itself. It's easy to add for implementations if it's not already possible, and it make so many use case cleaner or easier (like avoiding a node to be created by user in the XEP-0485 case). ✏

But it totally make sense that the server can have a PEP itself. It's easy to add for implementations if it's not already possible, and it makes so many use cases cleaner or easier (like avoiding a node to be created by user in the XEP-0485 case). ✏