Hello, When it comes to development, I find that XMPP servers using different "default" URLs for the WebSocket endpoint to be problematic, so even if the servers are not deployed it would be really useful if the upstream default configuration followed the convention.
wss://localhost:5443/ws ws://localhost:5443/ws It would help getting started with XMPP when WebSocket is the only transport available, in the case of xmpp.js, users have troubles finding out how to connect to their freshly deployed server on localhost. I have to ask them what is their server to find out what URL to use. Do you think it makes sense to add a note in the XEP to encourage vendors to change and/or add the endpoints as default configuration? Happy to send a PR. Regardless of that specific issue, if the use case is to address deployments where XMPP service operators do not have access to HTTPS configuration then I think the XEP should mention that the documentation is not solely destined to service operators but software vendors as well in that it is expected to use the implicit WebSocket endpoints as default configuration. As Jonas, I also have concerns regarding the overlap and possibly obsolescence of the useful XEP-0156: Discovering Alternative XMPP Connection Methods. The only way I can fully support this proposal is by moving "XEP-0156: Discovering Alternative XMPP Connection Methods" from "Advanced Client" to "Core Client" in the next compliance suite. The equivalent for TCP (srv records) is in core so why not its equivalent for web ? Getting srv records relevant for HTTP was impossible and IIRC painful for XMPP deployments, I would like to avoid going through the same situation for XMPP WebSocket. Cheers -- Sonny Piers [email protected] On Wed, Feb 3, 2021, at 09:19, Florian Schmaus wrote: > On 2/3/21 8:53 AM, Daniel Gultsch wrote: > > Hi Daniel, > > Thanks for your feedback. :) > > > On Wed, Feb 3, 2021 at 7:34 AM Jonas Schäfer <[email protected]> wrote: > >> The XMPP Extensions Editor has received a proposal for a new XEP. > >> > >> Title: Implicit XMPP WebSocket Endpoints > >> Abstract: > >> This document specifies implicit connection endpoints for XMPP over > >> WebSocket (RFC 7395). > >> > >> URL: https://xmpp.org/extensions/inbox/xep-iwe.html > > > > What's the issue with 0156? > > XMPP service operators may not always have the according HTTPS endpoint > under their control (xep156 § 3). Furthermore, it imposes additional > steps when configuring your XMPP service for WebSocket connectivity. > > I hit the latter: As I was working on Smack's integration tests for > WebSocket connections, I figured that my ejabberd already provided > WebSocket connectivity, but I did not had xep156 set up. Instead of > installing a HTTP server, configuring the TLS certificate and create the > XRD file, I simply implemented implicit WebSocket connection endpoints > in Smack (which was trivial)¹. > > > > If I'm understanding the XEP correctly the will probably only be used > > if no 0156 is found so a 'proper' client will always do both. > > I am not sure if 'do' here means 'implement' or 'perform'. In any way, a > client which strives for a maximum of successful connections is > incentivized to implement both. But as I said, I found the > implementation of implicit endpoints trivial in Smack. It is far easier > than implementing xep156. And, as you correctly identified, clients > could use implicit endpoints only if no xep156 information is found. > > > > However once we introduce implicit ones lazy clients will only use > > those and soon the implicit ones have to be set up be server. (Like > > try running an XMPP not on domain:5222 and connections will fail) > > I think I do not share this ressentiment. Yes, "lazy" and non-standard > compliant clients cause trouble and frustration. But I most cases those > clients are to blame, not the standard/specification/protocol. I see how > this is similar to the XHTML-IM discussion, so this is likely a > subjective matter. > > Eventually, it is a trade-off, and I believe the benefits of having > implicit endpoints specified overweight the risk of client > implementations become lazy. > > - Florian > > 1: That is also the reason the ProtoXEP's implicit connection endpoint > specification matches what ejabberd uses per default. > > > _______________________________________________ > Standards mailing list > Info: https://mail.jabber.org/mailman/listinfo/standards > Unsubscribe: [email protected] > _______________________________________________ > > > *Attachments:* > * OpenPGP_signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
