- Standards

XEP-0338 (Jingle Grouping Framework): feedback requested on PR
by Goffi 03 Nov '26

03 Nov '26

Hello everybody, Council is evaluating the following PR which update the XEP-0388 (Jingle Grouping Framework), a stable XEP: https://github.com/xsf/xeps/pull/1567 It adds a large large text which is enforcing rules. The way as I get it, it's not breaking existing implementation and it enforces rules which is a good thing. However, this PR has probably been missed by most, so we would like to have feedback from wider community before approving it or not. Thanks! Goffi (on behalf of Council)

1 0

Voice Notes
by Dave Cridland 02 Nov '26

02 Nov '26

Hi All, At the online summit there was some discussion about voice notes, which I hate. But, they've come up on a requirements doc I'm working to, so I thought I might see what the current best-practice / specs are. Do we have any? Are we using SIMS, SFS, OOB, or just putting a URL in the body and hoping everyone knows what we mean? Or all of the above? Dave.

4 3

[XEP-0171] Clarifying standard error conditions for translation services
by yiwei wu 02 Nov '26

02 Nov '26

Hi everyone, While implementing and reviewing XEP-0171 (Language Translation), I noticed that the specification currently defines very limited error handling (Section 4.3 only mentions <bad-request/> and <item-not-found/>). In real-world translation service scenarios, servers frequently need to communicate various rejection reasons to clients. However, the current specification does not explicitly define them. I suggest clarifying these error conditions to ensure consistency across different implementations. These error conditions fully adhere to RFC 6120, and descriptive details can be included within the standard <text/> element: 1. Rate limiting / Server busy / Overload Condition: <resource-constraint/> (type='wait') Description: The system currently lacks the resources to service this stanza; signals the client to back off and retry later. 2. Unsupported language pair or translation engine Condition: <feature-not-implemented/> (type='cancel') Description: The request format is valid, but the service does not support the requested language combination or specified engine. 3. Text payload exceeds maximum length Condition: <not-acceptable/> (type= 'modify') Description: The text length exceeds the per-request processing limit; signals the client to truncate or split the text before retrying. 4. Source language auto-detection failed Condition: <bad-request/> (type= 'modify') Description: The input content is too ambiguous or unrecognizable; prompts the client to explicitly specify the 'source_lang' attribute and resend. 5. Content policy / safety filter violation Condition: <policy-violation/> (type='cancel') Description: The submitted content violates service operational rules or safety policies. 6. Quota exhausted / Paid subscription required Condition: <subscription-required/> (type='auth') Description: The translation quota has been exhausted, or an active subscription plan is required (RFC 6120 natively provides this condition specifically for subscription scenarios). Looking forward to your thoughts.

2 3

Defining optional <reason/> element in <retracted/> (XEP-0424)
by yiwei wu 01 Nov '26

01 Nov '26

I would like to bring up an inconsistency between XEP-0425 (Moderated Message Retraction) and XEP-0424 (Message Retraction). In XEP-0425 (Example 9, illustrating a tombstone), the <retracted> element contains a <reason> child element. Under standard XML namespace inheritance rules, <reason> inherits the namespace of its parent (urn:xmpp:message-retract:1). However, XEP-0424 currently does not define or mention <reason> anywhere in its specification or XML schema for <retracted> I propose updating XEP-0424 to explicitly allow an optional <reason> element as a direct child of <retracted>. This element would contain human-readable text explaining why the message was retracted.Since the <reason> element would be optional, It aligns the formal definition in XEP-0424 with the usage already illustrated in XEP-0425. And does not introduce breaking changes to any known existing implementations.

4 4

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

29 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 17

Offloaded Delivery Receipts
by Dave Cridland 28 Oct '26

28 Oct '26

This is just a quick sketch of an idea. The server, when delivering to a client, generally knows when the client has received it. For those old-fashioned people still using TCP+SM, the SM </a> will do the trick nicely. For modern people using QUIC, we can detect the receipt via QUIC acks. In either case, the server could send a requested XEP-0184 receipt on behalf of the client. Clients would need to opt in, and there's some security issues around what the server should be responding for (roster vs non-roster, MUC, etc). But, it'd save a considerable amount of traffic which - I think, anyway - is tautological. I think there might be some edge-cases around delivery failures of ack packets, but maybe not? Or maybe the edge cases exist anyway with XEP-0184? Explaining why this won't work would be very welcome, I've not tried anything along these lines yet and it may be that the edge cases are too complicated to deal with. Dave.

1 0

Proposed XMPP Extension: Bookmarks hierarchy
by Daniel Gultsch 27 Oct '26

27 Oct '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Bookmarks hierarchy Abstract: This specification provides a way to organise bookmarks. URL: https://xmpp.org/extensions/inbox/bookmarks-hierarchy.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 7

Proposed XMPP Extension: Bookmark last known name
by Daniel Gultsch 27 Oct '26

27 Oct '26

The XMPP Extensions Editor has received a proposal for a new XEP. Title: Bookmark last known name Abstract: This document defines an XMPP protocol extension to allow users to pin PEP Native Bookmarks. URL: https://xmpp.org/extensions/inbox/bookmark-last-known-name.html The Council will decide in the next two weeks whether to accept this proposal as an official XEP.

6 10

UPDATED: XEP-0292 (vCard4 Over XMPP)
by Daniel Gultsch 25 Oct '26

25 Oct '26

Version 0.12.2 of XEP-0292 (vCard4 Over XMPP) has been released. Abstract: This document specifies an XMPP extension for use of the vCard4 XML format in XMPP systems, with the intent of obsoleting the vcard-temp format. Changelog: Fix automated entity example for removal of raw-IQ mode (ka) URL: https://xmpp.org/extensions/xep-0292.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

XMPP Council Agenda 2026-10-27
by Daniel Gultsch 25 Oct '26

25 Oct '26

Good Morning Council Members, the next XMPP Council Meeting will take place on, Tuesday, October 27 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-0070 (Verifying HTTP Requests via XMPP) * UPDATED: XEP-0292 (vCard4 Over XMPP) * UPDATED: XEP-0425 (Moderated Message Retraction) * Proposed XMPP Extension: Portable Import/Export Format for XMPP Components * Proposed XMPP Extension: Bookmarks hierarchy * Proposed XMPP Extension: Bookmark last known name 4) Items for voting a) Proposed XMPP Extension: Portable Import/Export Format for XMPP Components https://xmpp.org/extensions/inbox/pie-components.html b) Proposed XMPP Extension: Bookmarks hierarchy https://xmpp.org/extensions/inbox/bookmarks-hierarchy.html c) Proposed XMPP Extension: Bookmark last known name https://xmpp.org/extensions/inbox/bookmark-last-known-name.html d) XEP-0045: Standardize the muc#roomconfig_enablearchiving field in 0045 https://github.com/xsf/xeps/pull/1566 e) XEP-0338: Define active BUNDLE group updates https://github.com/xsf/xeps/pull/1567 f) XEP-0338: Add the XML Schema https://github.com/xsf/xeps/pull/1569 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

1 0