LAST CALL: XEP-0485 (PubSub Server Information)
This message constitutes notice of a Last Call for comments on XEP-0485. Title: PubSub Server Information Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub. URL: https://xmpp.org/extensions/xep-0485.html This Last Call begins today and shall end at the close of business on 2025-11-03. Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list: 1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol? 2. Does the specification solve the problem stated in the introduction and requirements? 3. Do you plan to implement this specification in your code? If not, why not? 4. Do you have any security concerns related to this specification? 5. Is the specification accurate and clearly written? Your feedback is appreciated!
Hello, Le lundi 20 octobre 2025, 19:35:36 heure d’été d’Europe centrale Daniel Gultsch a écrit :
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
yes
2. Does the specification solve the problem stated in the introduction and requirements?
yes
3. Do you plan to implement this specification in your code? If not, why not?
No, it's a server side implementation, and I don't plan in close future to use the data provided.
4. Do you have any security concerns related to this specification?
They are already addressed in the XEP (Privacy Consideration).
5. Is the specification accurate and clearly written?
Yes, but I think that the field `var` should use Clark notation as requested by XEP-0068: it uses the existing form with the namespace `urn:xmpp:serverinfo:0` which comes from XEP-0157 and adds its own field `serverinfo-pubsub-node`. I think that `{urn:xmpp:serverinfo:0}pubsub-node` should be used instead. Regarding the fact that there are already implementations in the wild, it's probably not trivial to change at this stage, but on the other hand, the Last Call and potential move to "stable" is the right occasion. For the sake of pragmatism, it’s probably not a blocker for the move to "stable". Thank you. Best, Goffi
It’s also worth adding that it would make sense to have a PEP service for the server itself (i.e., at `example.org` instead of `user@example.org`), which would simplify several use cases, including the XEP-0485 one. This would avoid the problem stated in § 7 Privacy Considerations:
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.
As with a PEP for the server itself, non-administrative users could not create anything. This PEP for server itself idea was already proposed by Mathieu Pasquet with an earlier version of XEP-0455. Best, Goffi
Hi Goffi! Thanks for that PEP suggestion. I wonder if the use-case is indeed simplified by using a PEP service for the domain itself: consumers of the data would still need to perform an additional verification, right? Instead of checking if the service advertises the serverinfo feature, consumers need to verify that the service is a PEP-service for the domain itself - which I think is basically done by checking for a _different_ feature? Offering more than one way that 'opt-in' can be verified by a consumer complicates implementations. That complexity could be 'solved' by mandating exactly one of the options, but in that case the PEP solution is likely to be least supported by current server implementations. I would favor the existing option because of that. As for the suggestion to switch to using the Clark notation for the new disco/info field: In my reading XEP-0068 mandates it only for fields not registered by the XSF itself. That doesn't apply to the field added by this pubsub-serverinfo XEP. That doesn't mean that we _cannot_ use Clark notation, of course, but what would be the benefit of moving to a Clark notation? I don't think it does away with the awkwardness of having either multiple XEP-0128-defined dataform-extensions, or merging them into one. I'm not immediately seeing a benefit of using Clark notation here. I love to hear your thoughts on this! Kind regards, Guus On Tue, Oct 21, 2025 at 9:32 AM Goffi <goffi@goffi.org> wrote:
It’s also worth adding that it would make sense to have a PEP service for the server itself (i.e., at `example.org` instead of `user@example.org`), which would simplify several use cases, including the XEP-0485 one. This would avoid the problem stated in § 7 Privacy Considerations:
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.
As with a PEP for the server itself, non-administrative users could not create anything.
This PEP for server itself idea was already proposed by Mathieu Pasquet with an earlier version of XEP-0455.
Best, Goffi_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org
On Mon, Oct 20, 2025 at 7:35 PM Daniel Gultsch <daniel@gultsch.de> wrote:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
Strictly speaking yes. It describes a way to gather statistics about the federated ecosystem. Personally I have no strong feelings about the usefulness of those statistics…
2. Does the specification solve the problem stated in the introduction and requirements?
Yes
3. Do you plan to implement this specification in your code? If not, why not?
No. Personally I just don’t care about those statistics tbh
4. Do you have any security concerns related to this specification?
No
5. Is the specification accurate and clearly written?
Yes.
(Belatedly, although I’ve shared the feedback prior to LC) On 20 Oct 2025, at 18:35, Daniel Gultsch <daniel@gultsch.de> wrote:
This message constitutes notice of a Last Call for comments on XEP-0485.
Title: PubSub Server Information Abstract: This document defines a data format whereby basic information of an XMPP domain can be expressed and exposed over pub-sub.
URL: https://xmpp.org/extensions/xep-0485.html
This Last Call begins today and shall end at the close of business on 2025-11-03.
Please consider the following questions during this Last Call and send your feedback to the standards@xmpp.org discussion list:
1. Is this specification needed to fill gaps in the XMPP protocol stack or to clarify an existing protocol?
It specifies something not otherwise done. I’m not sure I could claim it’s a real gap, nor that it’s ’needed’.
2. Does the specification solve the problem stated in the introduction and requirements?
Largely.
3. Do you plan to implement this specification in your code? If not, why not?
No (I don’t think it’s useful, and I’m concerned by the privacy implications).
4. Do you have any security concerns related to this specification?
I remain concerned about the privacy implications, even when opt-in (I guess maybe that a server operator might opt-in but not include it in their privacy terms is a social problem rather than a technical one, but whether users are able to understand the potential fingerprinting seems unlikely).
5. Is the specification accurate and clearly written?
AFAICS. /K
participants (4)
-
Daniel Gultsch -
Goffi -
Guus der Kinderen -
Kevin Smith