[Standards] Re: Proposed XMPP Extension: Happy Eyeballs

Thanks Guus, for putting the effort into writing the XEP But I am sorry, I feel similar like Travis. The main problem of the ProtoXEP is that its scope is too narrow. Focusing solely on SRV records and IPv4/IPv6 addresses misses the reality of diverse XMPP endpoint discovery mechanisms used by clients today, such as XEP-0156 and XEP-0487. That said, given the complexity that implementors face with the various XMPP transport methods, like BOSH (XEP-0206), QUIC (XEP-0467), and WebSockets (RFC 7395, XEP-0468), I see room for a XEP that guides implementors on how to achieve a reliable connection, even in the presence of challenging network conditions and hostile middleboxes. Daniel already provides two excellent points for client implementers: 1. only assume that the connection was successful after the XMPP stream was established 2. cache the last working connection's information (e.g., to work around hostile networks where DNS does not work) Furthermore, to deliver a good UX, clients need to try a limited amount of connection endpoints in parallel [1]. At least, that is what Smack's new connection architecture does. Some things that should be kept in mind here. For example, this should still respect the priority groups of SRV resource records. A document outlining best practices for establishing XMPP connections (both c2s and s2s), based on real-world experience, would be a valuable resource for the XMPP ecosystem. This document should address the challenges of diverse discovery mechanisms, transport methods, and network conditions to ensure robust and reliable XMPP communication. Finally, a nit: "Fully Qualified Domain Name" is not clearly specified, I suggest using "DNS name" instead. - Flow 1: Thanks to the current push towards featherweight threading systems in programming languages, this can be implemented very efficiently