- Standards

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

24 Oct '26

Version 1.0.3 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: Fix namespaces in examples (spw) 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

[XEP-0171] Clarification on rate limiting
by huxiangkun2003＠gmail.com 24 Oct '26

24 Oct '26

While implementing and reviewing XEP-0171 (Language Translation), I noticed that the specification currently lacks an explicit standard error response for scenarios where the translation service is busy, overloaded, or rate-limiting requests (e.g., hitting quota limits or temporary server congestion). According to RFC 6120, the `<resource-constraint/>` defined-condition with error type `wait` indicates that the entity lacks the system resources (CPU, memory, quotas, etc.) necessary to service the stanza, which fits this use case perfectly: ``` <iq type='error' id='translationReq' from='translation.robot.com' to='ace(a)example.com'> <error type='wait'> <resource-constraint xmlns='urn:ietf:xml:params:ns:xmpp-stanzas'/> </error> </iq> ``` (Note: depending on implementation, an optional application-specific error element or human-readable <text/> could accompany it if needed). Explicitly documenting this would improve interoperability and guide client developers on how to implement retry logic or display appropriate feedback to users, rather than treating rate-limiting as a generic/permanent failure.

1 0

Regarding spam emails
by Christos Tsichrinis 22 Oct '26

22 Oct '26

Can we sincerely talk about setting up a spam filter or at the very least, requiring Gmail addresses to first be manually reviewed by a human before they can start a thread? These weekly spam floods are definitely not just a single instance, and this is getting more and more annoying for me (and others I can imagine). Kindly, Christos Tsichrinis (a.k.a. oakchris1955)

2 1

XMPP Council Agenda 2026-08-25
by Daniel Gultsch 20 Oct '26

20 Oct '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, August 25 2026 at 15:30 UTC in xmpp:council@muc.xmpp.org?join The Agenda is as follows: 1) Roll call 2) Agenda Bashing 3) Editors update • UPDATED: XEP-0066 (Out of Band Data) https://xmpp.org/extensions/xep-0066.html • UPDATED: XEP-0515 (TLS Channel-Binding Downgrade Protection) https://xmpp.org/extensions/xep-0515.html • NEW: XEP-0518 (Payment Required) https://xmpp.org/extensions/xep-0518.html 4) Items for voting a) XEP-0143: Add author responsibility to submission process https://github.com/xsf/xeps/pull/1552 b) XEP-0490: Add security consideration for sender verification of PEP notifications https://github.com/xsf/xeps/pull/1554 c) XEP-0134: Add guideline against context-dependent elements https://github.com/xsf/xeps/pull/1558 d) XEP-0084: Fix example with both pubsub and HTTP source https://github.com/xsf/xeps/pull/1559 5) Pending votes none See the spreadsheet of doom: https://docs.google.com/spreadsheets/d/14gy_nhuTnqlktakJfLZ2Mc-jblSaG0na0Kh… 6) Date of Next 7) AOB 8) Close

4 4

Comments on ProtoXEP: Jingle Audio/Video Conferences
by Dave Cridland 20 Oct '26

20 Oct '26

Hi Jérôme, standardizers, I saw that Jérôme had resubmitted av_conferences, and since this is an area of interest of mine, and one I sadly lack the detailed understanding to drive, I reviewed it with some interest. Firstly, this is, in my view, a major step forward and I would welcome it being published as a XEP. This is despite my suspicion that it will need more work. The main areas are around signalling for some of the cases that are hinted at. For example, bounded/demand forwarding, resolution selection, and so on. The biggest structural change - I think - is that the spec assumes that participants would get one or more SSRCs bound to them, and I suspect the "right" way to achieve a good result in the client is to bind SSRCs to UX elements; so a SSRC maps to "The 4th most recent speaker", or "This pinned particiant", for example - and the Focus then instructs the SFU to map an inbound stream to that SSRC accordingly. That implies that <origin/>, which maps to the <content-add/> set in Jingle, would need to be replaced with something that's part of the <description-info/> instead. Obviously this is all with the caveat that I have no idea what I'm talking about, really... But, I would really love to see interoperable multiparty calls in XMPP. Dave.

2 1

Spec proposal: bookmark last known name
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hey everybody (bis), I submitted a(nother) proxoXEP today: <https://github.com/xsf/xeps/pull/1575>. A rendered version is at <https://nicoco.fr/bookmark-last-known-name.html>. The idea is for clients (or, wait for it: gateways) to set a bookmark extension "last-known-name" for MUCs in the PEP bookmarks. This last known name can then be used in the "start chat"-like dialog of clients for them to display a human-readable for the "chat" without (or before/while) querying its disco#info. Of course, this spec only makes sense if client developers think it does fill a gap. As a user, I know that there is a gap, because it happened a few times to me that I wanted to join a room from my new client, and couldn't figure out which bookmark item it was because it had never been joined before from this client (and the JID localpart was gibberish). Maybe it makes more sense to expect clients to disco#query all bookmark items instead. Side-note: maybe we should have some sort of registrar for standardized bookmark extensions, instead of having them all as separate XEPs? Maybe not. Community, what do you think? -- nicoco

1 0

Spec proposal: bookmarks hierarchy
by Nicolas Cedilnik 18 Oct '26

18 Oct '26

Hello all, Edhelas and I submitted a PR on github for a spec proposal: <https://github.com/xsf/xeps/pull/1574> A rendered version is at <https://nicoco.fr/bookmarks-hierarchy.htm>. The idea is to have an additional item in pubsub/pep nodes containing bookmark items, defining bookmarks directories. The bookmark items themselves have a dedicated extension referring to these directories, with a "weight" used to sort them within the categories. Our obvious use case is organising rooms in a XEP-0503 space, but it could possibly be used for organising PEP bookmarks too. Feedback welcome and appreciated! Have a nice sunday, -- nicoco

1 0

Re: XEP-0353 language clarification
by onf 15 Oct '26

15 Oct '26

On Thu Oct 15, 2026 at 8:35 PM CEST, Thilo Molitor wrote: > The privacy aspects are discussed here: https://xmpp.org/extensions/xep-0353.html#security > > Because exchanging messages with other entities is effectively a presence > > leak, an XMPP client that implements the receiving side of this specification > > MUST disable sending of accept messages by default and MUST enable the feature > > only as a result of explicit user confirmation. Such confirmation can be > > provided per request, by automatically allowing requests received from Jingle > > initiators in the responder's contact list, or through some other suitable > > means as long as sending accept messages does not occur by default. > > But granted this is not ideal for several reasons: 1. the <accept/> element > was a :1 namespace one, but we rolled that back to the :0 namespace where the > same functionality is called <proceed/>. Also <ringing/> should be added in > that section of the XEP as well. Indeed, I read that section as being about <proceed/> -- indicating that a device is ringing can hardly be called "sending [an] accept message". > Regarding Dino never sending <ringing/>: older versions of that XEP didn't > include a ringing indication, maybe Dino simply implements an earlier version > of XEP-0353? Yes, I already said that in the thread you quote: > > On 10/14/26 6:59 AM, onf wrote: > > > I just checked and version 0.3.1 of the XEP that Dino claims to > > > implement doesn't seem to contain any description of <ringing/>, which > > > explains it. Its messages related to this XEP likewise don't include > > > <store/> hints because that's not specified in that version either. ~ onf

1 0

Proposed XMPP Extension: MUC is ready
by Daniel Gultsch 15 Oct '26

15 Oct '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: MUC is ready Abstract: This specification provides a way for MUC components to inform clients that a room is ready to be re-joined. URL: https://xmpp.org/extensions/inbox/muc-ready.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 8

Aluminum Cable Market Enables Power Transmission
by wanrup07＠gmail.com 15 Oct '26

15 Oct '26

The transmission and distribution of electrical power across residential, commercial, and industrial applications depends on aluminum cables that provide reliable conductivity while offering advantages in weight and cost compared to copper alternatives. According to Market Research Future, the Aluminum Cable Market was estimated at USD 120.55 billion in 2024 and is projected to grow from USD 125.2 billion in 2025 to USD 182.85 billion by 2035, exhibiting a compound annual growth rate of 3.86% during the forecast period. Report Key Statistics Market Research Future's comprehensive analysis reveals that North America is the largest market for aluminum cables, with a valuation of USD 10.5 billion in 2023 expected to grow to USD 15.0 billion by 2032. Europe follows with a valuation of USD 12.0 billion in 2023, potentially escalating to USD 17.0 billion. The Asia-Pacific region dominates with a valuation of USD 14.0 billion in 2023, projected to reach USD 20.0 billion. The Power Transmission segment continues to dominate, while the Telecommunication segment is witnessing rapid growth. AAC enjoys the largest market share, while ACSR is the fastest-growing. Industry Trends: Sustainability and Renewable Energy The most significant trend in the aluminum cable market is the focus on sustainability. Aluminum cables are gaining traction due to their recyclability and lower environmental impact compared to traditional copper alternatives. Growth in renewable energy is driving demand. As solar and wind energy projects proliferate, the need for reliable and efficient cabling solutions is becoming more pronounced. Technological advancements are improving performance. Manufacturers are developing cables with enhanced performance characteristics. Challenges: Competition and Raw Materials Competition from copper cables affects market share in some applications. Raw material cost volatility affects prices. Technical requirements continue to evolve. Future Outlook: Smart Grid and Electric Vehicles The future of the aluminum cable market lies in expansion into renewable energy sector with specialized aluminum cables. Development of lightweight aluminum cables for automotive applications will drive demand. Implementation of smart grid technologies utilizing aluminum cabling solutions will enable new capabilities. Expert Discussion: Regional Market Dynamics Insights published by Market Research Future indicate significant regional variation in aluminum cable demand. North America's leadership reflects extensive infrastructure development, with key players including Southwire Company, General Cable, and AFL. Europe's market is driven by industrial applications, with key players including Nexans and Kabelwerk Eupen AG. Asia-Pacific is the fastest-growing market, with key players including LS Cable & System and Sumitomo Electric Industries. Conclusion The Aluminum Cable Market is positioned for sustained growth as electrification accelerates and infrastructure modernizes. While challenges related to competition, raw materials, and technical requirements persist, ongoing innovation ensures that cables will continue to improve. The evolution toward smart grid and electric vehicles will define the competitive landscape through 2035. Read More: https://www.marketresearchfuture.com/reports/aluminum-cable-market-33651

10 16