- Standards

SFS vs SIMS vs OOB vs...
by Dave Cridland 05 Nov '26

05 Nov '26

Hi all, I propose that we do SFS, and drop the others. It's a bit silly having three file sharing things. SIMS is Deferred, currently, which is as dead as an Experimental XEP can be, but adding a note at the top to state that it's recommended to do SFS instead seems sensible. OOB is Stable, I suggest we move it to Deprecated. SFS and FME are both Experimental, so need advancing through to sensibly Deprecate OOB. In summary then: 1) Last Call XEP-0446, move to Stable. 2) Last Call XEP-0447, move to Stable. 3) Deprecate XEP-0066 (with note pointing to XEP-0447). 4) Add similar note to XEP-0385 but leave in Deferred. I'd like to build consensus for this, so: - Does anyone object? If so, how, why, and what would fix this? - Does anyone agree with me? Can we improve the plan? Dave.

5 10

Update XEP-0359 to restrict origin-id to narrow use case for MUCs w/o stable_id
by Daniel Gultsch 05 Nov '26

05 Nov '26

Hi, XEP-0359 is currently the second most implemented experimental XEP¹ that we very urgently need to move to stable. Previous attempts and discussions around that were blocked by people being unhappy with origin-id as they see it as mostly redundant and unnecessary these days. (It wasn’t when the XEP got written 11 years ago) So I’m proposing an update to XEP-0359 in an attempt to make everyone happy - we keep origin-id but limit the scope to for what it was originally intended. This change also reflects what Conversations has been doing for a long while and what has been the tribal knowledge way of doing things for a while. I've pinged Florian to hopefully give his OK and then I would like to LC this very shortly afterwards. cheers Daniel ¹: I’m going to let you guess on the most implemented one. But that’s a something I think we can tackle soon too.

1 0

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 02 Nov '26

02 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