- Standards

UPDATED: XEP-0472 (Pubsub Social Feed)
by Daniel Gultsch 14 Oct '25

14 Oct '25

Version 0.2.1 of XEP-0472 (Pubsub Social Feed) has been released. Abstract: This specification defines a way of publishing social content over XMPP. Changelog: * Clarify text in Reply-To section to show that the XMPP link is mandatory and that the HTTP link is optional. (jp) URL: https://xmpp.org/extensions/xep-0472.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0471 (Calendar Events)
by Daniel Gultsch 14 Oct '25

14 Oct '25

Version 0.2.0 of XEP-0471 (Calendar Events) has been released. Abstract: This specification describe how to handle calendar events with XMPP. Changelog: Modified title for "Calendar Events". Updated short-name and namespaces accordingly. (jp) URL: https://xmpp.org/extensions/xep-0471.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0248 (PubSub Collection Nodes)
by Daniel Gultsch 14 Oct '25

14 Oct '25

Version 0.5.0 of XEP-0248 (PubSub Collection Nodes) has been released. Abstract: This specification defines the nature and handling of collection nodes in the XMPP publish-subscribe extension. Changelog: * Enhance 'Discover Nodes' section with hierarchy / Collection Nodes description and examples * Move the Service Discovery Identity type 'collection' from XEP-0060 to XEP-0248 * Move collection-specific Service Discovery Features from XEP-0060 to XEP-0248 * Move process for changing node of type leaf to collection from XEP-0060 to XEP-0248 * Move requirement to support pubsub#notify_config for collection nodes from XEP-0060 to XEP-0248 (gdk) URL: https://xmpp.org/extensions/xep-0248.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0070 (Verifying HTTP Requests via XMPP)
by Daniel Gultsch 14 Oct '25

14 Oct '25

Version 1.0.2 of XEP-0070 (Verifying HTTP Requests via XMPP) has been released. Abstract: This specification defines an XMPP protocol extension that enables verification of an HTTP request via XMPP. Changelog: (see in-document revision history) URL: https://xmpp.org/extensions/xep-0070.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

UPDATED: XEP-0060 (Publish-Subscribe)
by Daniel Gultsch 14 Oct '25

14 Oct '25

Version 1.28.0 of XEP-0060 (Publish-Subscribe) has been released. Abstract: This specification defines an XMPP protocol extension for generic publish-subscribe functionality. The protocol enables XMPP entities to create nodes (topics) at a pubsub service and publish information at those nodes; an event notification (with or without payload) is then broadcasted to all entities that have subscribed to the node. Pubsub therefore adheres to the classic Observer design pattern and can serve as the foundation for a wide variety of applications, including news feeds, content syndication, rich presence, geolocation, workflow systems, network management systems, and any other application that requires event notifications. Changelog: * * * * * * * * * (gdk) URL: https://xmpp.org/extensions/xep-0060.html Note: The information in the XEP list at https://xmpp.org/extensions/ is updated by a separate automated process and may be stale at the time this email is sent. The XEP documents linked herein are up-to- date.

1 0

Yttyyy
by James Bohamie 13 Oct '25

13 Oct '25

Jamesbohamie(a)gmail.com

1 0

Yttyyy
by James Bohamie 13 Oct '25

13 Oct '25

Gffffy

1 0

XEP-0386 Bind2 Notes
by Dave Cridland 13 Oct '25

13 Oct '25

Hi all, Implementing this one has thrown up a few observations. 1) There's a note in 3.2 that says that if resumption fails, the server MUST include the failure in the response, and then proceed to process the bind request. But, it's only just finished saying that the bind request has to be processed before sending the response. I'm being picky, of course. 2) 3.2.1 says that the <tag/> SHOULD be included verbatim, which makes sense - but then also says it SHOULD (recommended, but same thing) be a prefix. These have the same force, so why are they distinct? Do clients expect a substring here or a prefix? Obviously a prefix *is* a substring, but I'm thrown by this being included twice with RFC 2119 language. 3) 3.2.1 also says the syntax SHOULD be "tag" / "rando bit", but then follows this with Example 4, which shows a dot instead. This makes me wonder why there's a SHOULD there. Do clients expect a solidus or a period? Do they care? If not, why is this a SHOULD? Why have *three* SHOULDs relating to the same thing? The last one seems to encompass the first two, and then it's ignored in the examples. 4) When discussing the <bound/> element 3.2.1 has a SHOULD for including the MAM state - is this indicating that servers supporting Bind2 SHOULD implement MAM, and in particular the urn:xmpp:mam:2 version? Clients do not request this implicitly, unlike the other interactions, making Bind2 intrinsically bound (if you'll pardon that pun) to a specific MAM version - this is evident in the schema, in fact. - Note that Conversations at least appears to only initiate Bind2 if MAM is supported - although doesn't appear to have any problem if the MAM summary element is omitted - making it appear as though MAM support is a MUST, despite including the metadata being a SHOULD still... Though I think the only way Conversations could know if via the caps feature hash in features, suggesting bind2 never works first time. 5) Similarly, 3.2 indicates that the server MUST do one thing that requires MAM, and another thing that relies on it being supported. 3.2.1 somewhat suggests that XEP-0280 and XEP-0352 are also mandatory to support, though I think that's just cumbersome language. Interestingly the document metadata says it does depend on MAM and Carbons - but not CSI. I don't think it does depend on Carbons, or should depend on MAM (but probably does). 6) If an inline feature request is unsupported or unrecognised, what does the server do? Ignore it silently? This is of particular interest because some inline feature requests don't have a confirmation they succeeded. 7) If authentication is successful, but bind fails, does the server say that authentication has failed? With what error? Or, is bind2 always expected to succeed? Not including the <bound/> element appears to trigger Conversations into thinking the session has not been bound, even if the authorization-identifier is a full jid. But! XEP-0388 says that a full jid here means that resource binding has occurred (that was intentional; but clearly that's not what's been implemented, so I'd better remove that!) 8) Unexpectedly, the <inline/> of the bind2 feature is mandatory even when empty; was this intentional? 9) 3.2.1 is entitled "resource identifier generation", but continues into discussing the XEP-0280 integration for example. Fixes: I think we may find we're doomed to stick with this version, but concretely: a) I think I'd have MAM advertised within <inline/>, and optional. This is a breaking change, though we could circumvent it by saying that bind2 can do the MAM stuff unilaterally, and clients SHOULD include it if they want it - but that depends on what servers might do if they're faced with a MAM request they don't understand. b) All inline features ought to have explicit confirmation, I think, but that's a breaking change. We could also include a generic inline feature failure indication ("<failed var="urn:xmpp:failed-extension:0"/>") to say that a requested feature has failed (or been unrecognised) and made no changes. And we could make an explicit confirmation at least a SHOULD for future servers. c) I'd love to tidy up some of the specification language generally. Fun (ish) fact: I'll almost certainly have an extraneous inline <feature var="urn:xmpp:mam:2"/> for Openfire because MAM is a plugin, and special-casing it for Bind2 will be rather awkward. Dave.

1 0

Interplanetary XMPP
by Peter Saint-Andre 13 Oct '25

13 Oct '25

No, the subject line of this message is not a joke. :-) The IETF has formed a "TIPTOP" working group to study and adapt Internet protocols for communication over interplanetary distances. [1] If anyone here is interested in this topic, I encourage you read their documents [2] and sign up for their email discussion list [3]. Thanks for your attention! Peter [1] https://datatracker.ietf.org/wg/tiptop/about/ [2] https://datatracker.ietf.org/wg/tiptop/documents/ [3] https://mailarchive.ietf.org/arch/browse/deepspace/

7 9

Pubsub feature advertisement
by Guus der Kinderen 06 Oct '25

06 Oct '25

Hi all! MUST a pubsub service advertise <feature var=' http://jabber.org/protocol/pubsub'/> with service discovery 'info' responses? XEP-0060 shows this being done in examples 8 and 18, but there is no normative text that defines this. The feature is not listed in its "Feature Summary" section, and is not registered with the Registrar. There has been a discussion around this in the XSF's Discussion chat room today (logs here: https://logs.xmpp.org/xsf/2025-10-03#2025-10-03-f173fd843da7c3ee ). There are implementations in the wild that require that feature to be advertised, while other software doesn't advertise it. Given the conflicting implementations, I believe that it would be good to have normative text be added to XEP-0060 to clarify things. I'm not sure yet what that text should be. What do you think? Kind regards, Guus

3 6