- Standards

Rrf
by louisyves618＠gmail.com 28 Aug '25

28 Aug '25

Ffgh

1 0

UPDATED: XEP-0167 (Jingle RTP Sessions)
by Daniel Gultsch 25 Aug '25

25 Aug '25

Version 1.2.3 of XEP-0167 (Jingle RTP Sessions) has been released. Abstract: This specification defines a Jingle application type for negotiating one or more sessions that use the Real-time Transport Protocol (RTP) to exchange media such as voice or video. The application type includes a straightforward mapping to Session Description Protocol (SDP) for interworking with SIP media endpoints. Changelog: Make 'ssrc' attribute 'xs:unsignedInt' (32-bit) instead of 'xs:string' to match RFC3550. (lnj) URL: https://xmpp.org/extensions/xep-0167.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.

2 1

UPDATED: XEP-0455 (Service Outage Status)
by Daniel Gultsch 25 Aug '25

25 Aug '25

Version 0.4.0 of XEP-0455 (Service Outage Status) has been released. Abstract: This document defines an XMPP protocol extension that enables server administrators to communicate issues with the server to all users in a semantic manner. Changelog: Remove leftover pubsub references, add accessibility considerations. (mp) URL: https://xmpp.org/extensions/xep-0455.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-0388 (Extensible SASL Profile)
by Daniel Gultsch 25 Aug '25

25 Aug '25

Version 1.0.4 of XEP-0388 (Extensible SASL Profile) has been released. Abstract: This document describes a replacement for the SASL profile documented in RFC 6120 which allows for greater extensibility. Changelog: Schema should use all instead of sequence (dg) URL: https://xmpp.org/extensions/xep-0388.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-0317 (Hats)
by Daniel Gultsch 25 Aug '25

25 Aug '25

Version 0.3.0 of XEP-0317 (Hats) has been released. Abstract: This specification defines a more extensible model for roles and affiliations in Multi-User Chat rooms. Changelog: Add hat creation and detruction flows; add hue optional parameter; add chatroom presence hats broadcast; complete disco#info; clarify how the service should broadcast updated hats; typos; standardize the form fields; (tj) URL: https://xmpp.org/extensions/xep-0317.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-0198 (Stream Management)
by Daniel Gultsch 25 Aug '25

25 Aug '25

Version 1.6.3 of XEP-0198 (Stream Management) has been released. Abstract: This specification defines an XMPP protocol extension for active management of an XML stream between two XMPP entities, including features for stanza acknowledgements and stream resumption. Changelog: Remove leftover <optional/> and <required/> children in <sm/> element. (egp) URL: https://xmpp.org/extensions/xep-0198.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

Re: Receiving a pong signal from an offline JID
by Peter Waher 20 Aug '25

20 Aug '25

Hello Schimon (etl al) > I am working on a news service for XMPP, which sends messages according > to status. > > When JID is offline, service should stop. Sounds like you would benefit from using PEP (XEP-0163) which accomplishes this. The publisher publishes a PEP event with its new service namespace, and only online entities with a presence subscription, and a corresponding service-detectable feature requesting PEP events with the corresponding news namespace, will receive the event. In this case, there's no need for the service to manually check subscribers and their current online presence. Best regards, Peter Waher

2 2

Receiving a pong signal from an offline JID
by Schimon Jehudah 19 Aug '25

19 Aug '25

Good day. I am working on a news service for XMPP, which sends messages according to status. When JID is offline, service should stop. Resources --------- As XMPP is presence oriented, it is needed to set extra measures, such as collecting detected resources, in order to be certain that a subject JID is indeed offline. This measure is still tested. Signals ------- I am experimenting with XEP-0199: XMPP Ping as a possible mean to confirm that an account is offline. However, while asking for a pong signal from a full JID (JID with a resource) returns an empty respond, asking for a pong signal appear to always to work when querying a bare JID (JID without a resource). PONG: sch(a)pimux.de/gajim.TN7Y65AS None PONG: sch(a)pimux.de 0.09115195274353027 PONG: sch(a)pimux.de/gajim.TN7Y65AS None PONG: sch(a)pimux.de 0.10207772254943848 My expectation was to have no respond for bare JID, when there is no connected instance to a given JID. Please advise. Kind reagrds, Schimon

2 2

Reconsider XEP-0146: Remote Controlling Clients
by Schimon Jehudah 19 Aug '25

19 Aug '25

Good day. I would want to ask the XSF members to reconsider XEP-0146 for a couple of reasons. * To educate and inform people of Ad-Hoc Commands, a feature which is exclusive to XMPP. * To control other clients when special situationn arises. For several days I have a connected XMPP client instance from my Movim instance which indicates that my JID is available, even though I deem that it should be offline. https://xmpp.org/extensions/xep-0146.xml XEP-0146: Remote Controlling Clients Kind regards, Schimon

1 0

Client Presence Probes
by Schimon Jehudah 17 Aug '25

17 Aug '25

Good day. Question ======== Is it possible for XMPP clients to actively probe for presence? JabberCard ========== I have created JabberCard, an HTML invitation page for XMPP. https://git.xmpp-it.net/sch/JabberCard https://git.0ut0f.space/doesnm/JabberCard JabberCard is based on the module Slixmpp and is an XMPPP client. Idea ==== Months ago, I was advised to add support for status, mood, and activity. I think that it is a good idea. Presence ======== However, it appears that actively probing for presence by XMPPP clients is not specified in the standard. According to the standard, only servers handle that task. 4.3. Presence Probes > Presence probes SHOULD NOT be sent by a client, because in general a > client will not need to send them since the task of gathering > presence from a user's contacts is managed by the user's server. > However, if a user's client generates an outbound presence probe then > the user's server SHOULD route the probe (if the contact is at > another server) or process the probe (if the contact is at the same > server) and MUST NOT use its receipt of the presence probe from a > connected client as the sole cause for returning a stanza or stream > error to the client. https://xmpp.org/rfcs/rfc6121.html#presence-probe Is it possible for XMPP clients to actively probe for presence? Please advise. Kind regards, Schimon

2 2