20 Oct
2025
20 Oct
'25
7:35 p.m.
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(a)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!
21 Oct
21 Oct
9:14 a.m.
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(a)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
9:32 a.m.
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(a)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
22 Oct
22 Oct
8:53 p.m.
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(a)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(a)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(a)xmpp.org
To unsubscribe send an email to standards-leave(a)xmpp.org
11 Nov
11 Nov
3:54 p.m.
On Mon, Oct 20, 2025 at 7:35 PM Daniel Gultsch <daniel(a)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.
4:48 p.m.
(Belatedly, although I’ve shared the feedback prior to LC)
On 20 Oct 2025, at 18:35, Daniel Gultsch <daniel(a)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(a)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
1
days inactive
23
days old
5 comments
4 participants
participants (4)
-
Daniel Gultsch -
Goffi -
Guus der Kinderen -
Kevin Smith