On Mittwoch, 27. September 2017 08:51:48 CEST Dave Cridland wrote: > The rules on "two implementations" are, I believe, aimed to correspond > to RFC 2026's Section 4.1.2, with the addition of licensing > requirements. > > I'd note, in particular, the second paragraph: > > The requirement for at least two independent and interoperable > implementations applies to all of the options and features of the > specification. In cases in which one or more options or features > have not been demonstrated in at least two interoperable > implementations, the specification may advance to the Draft Standard > level only if those options or features are removed. > > This does not have procedural force in the XSF, however I think it's a > sensible consideration - it makes little sense to include options not > exercised. > > > 1. Yes Conversations supports SNI[1] and ALPN[2] where available. These > > are guaranteed to be in android 4.2 and 4.4 respectively, and *might* be > > supported earlier depending on vendor. According to the stats[3] this > > means ~92% of androids currently in use support both. > > FWIW, XEP-0001 talks about implementations, rather than deployment, > but this information is nevertheless useful, thanks.
aioxmpp as client library supports this XEP minus ALPN. If ALPN support in a second client implementation is all it needs, I can probably fix that in a week or so (I took a quick look, the TLS library supports it). I don’t have a server to test against though, and thus it hasn’t been on my short list until now. > So we end up with: > > * ALPN seems to be a MAY for servers, and at most a SHOULD for clients > (but probably a MAY). > * SNI is a MUST for clients but a SHOULD for servers, noting that > multiple certificates will necessitate SNI to be properly > interoperable. > * With these changes, anything supporting "legacy SSL", or "xmpps", is > conformant on the server side for C2S - but none of these support SNI > or ALPN. > * We have one client implementation, supporting SNI and ALPN. > * We have one S2S implementation, supporting SNI. > > On that basis, I don't *think* we can include S2S in Final, We’re talking about Draft here, not Final. But I assume this is a typo? > which is > frustrating. We probably can include C2S, but with only one > client-side implementation it's playing a little fast and loose, I > think, and I'd much rather see SNI support server-side to feel > satisfied that SNI is actually covered. kind regards, Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
