vendors to change and/or add the endpoints as default configuration?
An encouraging note sounds fine.
Regardless of that specific issue, if the use case is to address deployments where XMPP service operators do not have access to HTTPS
Note that there are also other motivations for this ProtoXEP.
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.
I have no strong opinion on that. Not sure if WebSocket (RFC 7395) should go into 'Core', but it appears very sensible that WebSocket support should also require support for xep156.
The equivalent for TCP (srv records) is in core so why not its equivalent for web ?
I don't see xmpp-*. SRV RRs in 'Core'. Only xmpps-*. SRV RRs are in 'Advanced', and that is probably because they are an extra XEP.
And since it appears you could be RFC-6120 compliant without implementing SRV RRs lookup, I would similarly argue as above: The compliance suite should explicitly state that for RFC-6120 style connections, proper SRV RRs handling is REQUIRED. This would mean that "lazy" clients, as Daniel describes then, could not declare conformity with the compliance suites.
- Florian
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] <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>> > 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 listInfo: https://mail.jabber.org/mailman/listinfo/standards <https://mail.jabber.org/mailman/listinfo/standards> Unsubscribe: [email protected] <mailto:[email protected]>_______________________________________________ *Attachments:* * OpenPGP_signature_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
OpenPGP_signature
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
