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.htmlWhat'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.
- Florian1: That is also the reason the ProtoXEP's implicit connection endpoint specification matches what ejabberd uses per default.
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
