Hi Özcan, Hi Peter, thanks for your feedback. Much appreciated. It seems sensible to address the Mail also on the XEP Author. Which I now did. - Florian On 23/09/2026 23.45, Özcan Oğuz via Standards wrote:
Hello everyone,
I have been implementing XEP-0332 in xmpp-httpx, a TypeScript library for Node.js and browsers, and would like to share implementation experience and offer to help co-author a revision.
The library implements paths for all seven body mechanisms, with documented interpretations and deviations. It has been exercised over Prosody 13 and used by several browser integrations and an HTTP-origin gateway. These are implementation and integration results, not independent XEP-0332 interoperability tests. I also created a WebExtension and Dillo extension for httpx.
Code: https://github.com/ooguz/xmpp-httpx <https://github.com/ooguz/ xmpp-httpx>
Protocol notes: https://github.com/ooguz/xmpp-httpx/blob/main/docs/ protocol-notes.md <https://github.com/ooguz/xmpp-httpx/blob/main/docs/ protocol-notes.md>
Test coverage and interoperability matrix: https://github.com/ooguz/ xmpp-httpx/blob/main/docs/interop.md <https://github.com/ooguz/xmpp- httpx/blob/main/docs/interop.md>
There are two related areas I would like to discuss and clarify:
1. Clarifying and updating the existing protocol
The request/response model has been useful in practice. Several details nevertheless need clarification or an explicit design decision:
*
Chunked transfer completion and failure: empty transfers, missing or conflicting chunks, bounded buffering, and the processing rules for the existing close element. Zero-based numbering is already specified.
*
The unit of maxChunkSize and guidance for accounting for Base64 expansion and the complete stanza envelope.
*
The relationship between an embedded Jingle offer and ordinary Jingle session initiation, acknowledgement, acceptance, and rejection.
*
The allowed request-body mechanisms and their discovery. In particular, our use of IBB for request bodies goes beyond the current response-only restriction.
*
A consistent distinction between malformed HTTPX requests, unsupported transport mechanisms, HTTP errors, and failures after the response IQ has already been sent.
*
Gateway header and body handling, including the existing description of preserving HTTP chunk framing.
*
A migration policy for SIPUB’s deprecated dependencies.
I would separate corrections to examples from behavioral changes, and document our implementation choices as such rather than assume that they should become the specification.
1. An optional CONNECT extension
A second application suite, n146 (the reason why I started development in the first place) uses the same library as a web-over-XMPP proxy. It is not yet publicc ready and is not an independent protocol implementation.
For that application, we implemented an experimental CONNECT mapping:
*
A req with method='CONNECT' identifies a host and port using authority-form.
*
A successful resp identifies an IBB session.
*
The proxy opens that session, which carries tunnel bytes in both directions.
This reuses IBB’s explicitly defined bidirectional operation. It extends XEP-0332, which currently excludes CONNECT.
In our tests, the mapping supports HTTPS access through HTTP CONNECT and SOCKS5 frontends, including concurrent browser traffic in Chromium and Firefox. These are application-level results; I would not present them as proof that the tunnel semantics are complete.
Before proposing normative text, I think we need agreement on connection establishment, graceful shutdown versus abort, pending-data handling, timeouts, peer/session binding, and failures between the successful response and IBB establishment. The current implementation’s shutdown choices need further review.
Discovery also needs to identify the precise supported wire format. I would not reuse one feature identifier for both the existing experimental req form and a future standalone connect element without defining how peers distinguish them.
For an initial profile, IQ-carried IBB seems a useful baseline. Windowing, bounded buffering, and scheduling across concurrent streams could be documented as implementation guidance, with reproducible benchmarks rather than general performance guarantees.
CONNECT and absolute-form forwarding would also require explicit destination authorization, network access restrictions, resource limits, and security/privacy guidance distinguishing XMPP transport encryption from TLS carried inside a tunnel.
I would be happy to work with the author and interested implementers on:
1.
A focused patch addressing existing ambiguities and example errors.
2.
A separately reviewable CONNECT and request-target proposal, either within XEP-0332 or as a companion extension.
3.
Shared wire fixtures and interoperability tests against an independent implementation.
I can contribute XML patches, examples backed by test fixtures, and the public implementation as an interoperability target. I would welcome feedback on the scope before combining these changes into a revision.
Would updating XEP-0332 be the preferred direction, and should CONNECT be considered within that work or separately? Pointers to other implementations, or to earlier discussion of its exclusion, would also be very useful.
Sincerely, Özcan Oğuz
_______________________________________________ Standards mailing list -- standards@xmpp.org To unsubscribe send an email to standards-leave@xmpp.org