On Wed, Feb 3, 2021, at 03:19, Florian Schmaus wrote: > XMPP service operators may not always have the according HTTPS > endpoint under their control
In what situation would you not have the HTTPS endpoint? If you only have an XMPP server config and can't modify anything else, it doesn't seem unreasonable to say "you can't run websockets in your very restricted setup, sorry". I'd love for as many people as possible to be able to run an XMPP server, but at some point you are administering a server and need to have enough access to actually setup and administer things. > Furthermore, it imposes additional steps when configuring your XMPP > service for WebSocket connectivity. I do agree that setting up an HTTP server or configuring DNS records can be an annoying burden, but it doesn't seem big enough that we should try to work around it for the sake of a handful of people who have a very restricted setup. We already have issues with servers that don't setup SRV records for the normal TCP protocol and you have to guess if they're using 5222, or the legacy TLS port, or TLS on 5222, etc. we shouldn't add to that guessing game. > 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. This is part of the problem, as Daniel pointed out. I don't see this as widely useful but if we do implement it it's easier so fewer people will do it the "right" way and the less useful thing becomes the defacto initial implementation. I'm sure it's trivial to implement, but that doesn't mean we should standardize it. > 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. I don't believe that's a subjective matter in either case. If you make the easiest thing to do the wrong thing, clients will do it. That's their fault, but it's also our fault for not designing protocols that are robust in the face of human error. We can't prevent every lazy client dev from doing bad things, but we can certainly try to make the default the easy thing. That being said, I don't think it's nearly as bad if we add an implicit fallback for websockets, I just don't think it's necessary either and adds complexity for little to no benefit. > Eventually, it is a trade-off, and I believe the benefits of having > implicit endpoints specified overweight the risk of client > implementations become lazy. I still don't understand what these benefits are. A message to this list to help me understand what the tradeoffs are would be helpful I think. Is it just that a handful of people might not be able to run an HTTP server? That seems like it's likely a very tiny (possibly "empty") group of situations to cater too. > 1: That is also the reason the ProtoXEP's implicit connection endpoint > specification matches what ejabberd uses per default. If we do end up adopting this protocol, we should not use the defaults from Ejabberd. The endpoint "/ws" is too generic and may conflict with other HTTP endpoints on services that run more than just XMPP on their domains. If anything let's use "/xmpp-websocket" which is used in all the examples in RFC 7395 so that we at least sort of "namespace" the endpoint to XMPP land and make it obvious what it's for / make conflicts less likely. Alternative coming in a separate email since I think it might be a separate thread. —Sam -- Sam Whited _______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
