On 09.01.2018 05:19, Travis Burtrum wrote: > It is also clear I didn't think about this too hard when writing > XEP-0368, because I clearly (to me) assume SRV fallback will happen if a > complete XMPP connection is not successful, because under Implementation > Notes I say: > >> Server operators should not expect multiplexing (via ALPN) to work in >> all scenarios and therefore should provide additional SRV record(s) >> that do not require multiplexing (either standard STARTTLS or >> dedicated direct XMPP-over-TLS). This is a result of relying on ALPN >> for multiplexing, where ALPN might not be supported by all devices or >> may be disabled by a user due to privacy reasons. > > While I don't explicitly say it, if a port required ALPN to multiplex, > it will generally end up connecting you to a non-XMPP server without > ALPN, meaning you will get back invalid XML, other junk, and/or an > invalid TLS cert.
If I understood correctly, then a basic example where a xep368 fallback after a TCP connection was established would be beneficial is, if there is a high priority SRV RR pointing to a ALPN required destination. And another SRV RR with a lower priority pointing to a non-ALPN destination. A client supporting xep368 but not ALPN would, without fallback, immediately fail, neglecting the valid fallback position. You mention multiple ways in how the non-ALPN client connection to a ALPN-required destination could fail, (which appears to contribute to the confusion): - Invalid Cert - Invalid XML (how could that happen BTW?) - (are there more?) I see the following options: 1. xep368 provides an implementation hint that such a fallback would be a good idea. 2. xep368 makes ALPN mandatory 3. do nothing Is that correct? - Florian
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
