I agree with the points raised, but I suggest we forget about public deployments, looks like the only valid use case for this proposal is to have default endpoints for non-public facing services (CI, localhost, development, ...)
Here is my proposal: The XEP is a recommendation for server to default to `ws://service:5280/xmpp-websocket` and `wss://service:5443/xmpp-websocket` instead of current arbitrary endpoints. The XEP mentions that these are not recommended endpoints for public deployments and that protocol wss and port 443 advertised over XEP 0156 is preferred. That's it. As a follow up: Client and client libraries are free to choose to fallback to these endpoints if the service is not a FQDN. Regardless of this proposal, 0156 should become mandatory for compliance suite web core. WDYT? -- Sonny Piers [email protected] On Wed, Feb 3, 2021, at 18:02, Florian Schmaus wrote: > On 2/3/21 5:43 PM, Dave Cridland wrote: > > On Wed, 3 Feb 2021 at 07:33, Jonas Schäfer <[email protected] > > <mailto:[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 > > <https://xmpp.org/extensions/inbox/xep-iwe.html> > > > > > > I'm leaning toward a veto here: > > > > 1) I don't think we want to mandate that a host listens by default on > > non-TLS services. > > I am not thinking of this as mandating anything, but more of "if you are > listening for WebSockets under the XMPP service domain's DNS name, you > may as well use these parameters". > > > > 2) This also weakens the need to run XEP-0156 in any form. I get that > > > this is a bit of a pain, but it's also the best option we have. Relaxing > > the need for generic websocket usage to use this pathway also > > strengthens the need to operate the XMPP service on the host the service > > name resolves to by address lookup. I don't want to increase that need > > in production services, and otherwise this has the effect of reducing > > interoperability. > > Yep, and I think this case is far more valid, as in the "RFC 6120 > non-SRV fallbacks hinder interoperability" argument. > > But as others have shown interest in this, there also appears to be a > use case for something like "implicit XMPP websocket parameters". > > What if we rephrase the document to something like "Suggested default > XMPP-over-WebSocket values"? > > with a weakened version of Sonny's PR > https://github.com/xsf/xeps/pull/1035/ like > > "XMPP server vendors may consider to use this values for the WebSocket > parameters of their default configuration (file)." > > Would that constitute a resolution for your points? > > - Florian > > > _______________________________________________ > 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] _______________________________________________
