On Wed, Feb 3, 2021, at 14:20, Florian Schmaus wrote: > On 2/3/21 1:47 PM, Sonny Piers wrote> 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? > > An encouraging note sounds fine. Great - I will 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 > > 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. WebSocket (RFC 7395) is already in Web core.
To clarify; My proposal is for the Web Compliance Suite 2022 to require both core server and core client to implement XEP-0156. > > 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. xmpp-* srvs are in RFC 6120 https://xmpp.org/rfcs/rfc6120.html#tcp-resolution-prefer I suggest moving this conversation somewhere else though. > > - 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 list > >> Info: 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] > > _______________________________________________ > > > > > _______________________________________________ > 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] _______________________________________________
