On Mittwoch, 20. Dezember 2017 13:50:11 CET Georg Lukas wrote: > * Jonas Wielicki <jo...@wielicki.name> [2017-12-20 13:06]: > > > a) the server inspects the client connection type and returns the port > > > for the same connection type in 0198/location, i.e. if the client > > > connected via Direct-TLS to 5223, the server will return server:5223. > > > This will obviously break clients that support Direct-TLS but fall back > > > to STARTTLS in 0198. As Direct-TLS is rather fresh, the impact of this > > > might be bearable, despite both specs being 'Draft'. > > > > You’d still have to know which port is which, wouldn’t you? > > No, you don't. The client just needs to remember the current connection > type and reuse it when reconnecting to the port it obtains from > 'location'.
Okay. That’s a bit less worrying, but the same argument I put below applies here. > > > b) the server only returns the hostname, omitting the port, and the > > > client uses the original (cached) list of ports to connect via its > > > preferred method, allowing Direct-TLS resumption. > > > > This seems worse, and more layer-breaking than what clients already have > > to > > do. > > Could you please elaborate the problems you are seeing? > > I considered this one to be the cleanest solution, as it does not > violate current specifications. It merely requires that all instances > of a cluster use the same port mapping. The client needs to cache the > initial SRV lookup result to have the mapping connection-type -> port, > but with 'location' based resume it shouldn't need to re-run SRV lookup > anyway. Okay, so this may just be me. But in aioxmpp, there is just a connect_xmlstream function [1], which (nearly) only receives the domain name as argument and returns an established XMLStream object. It handles SRV lookups etc., but that information is never stored anywhere outside that function. (The @location stuff is handled with an optional argument of connection options (host, port, connection_type), essentially, which takes precedence over SRV lookups.) To be able to cache the SRV lookups, I need another abstraction breakage by passing DNS-level information *up* to the code managing the stanza stream. This is worse than passing information *down* (we need to do that anyways, e.g. the domain name). It can be done, but I find it ugly. > > I think it would make more sense to specify the SRV-record field. > > I would agree in theory, but SRV records are a binary representation > combining multiple properties (_service._proto.service, priority, weight, > port, target), which have a convention for ASCII representation. > > What we need is the first part of the label (_service._proto - to store > the connection type), port, and target, with the target being a > synthetic value that's probably not even present in the original SRV > record because it is an individual server instance instead of a typical > cluster-wide round-robin name. > > Existing implementations contain code to process SRV records from their > binary form in DNS responses, but not to process the ASCII > representation which is typically only present in the DNS server > implementation (RFC 1035 §5). I'm pretty sure we do not want to > introduce a dependency on _that_ in XMPP. ``_service`` and ``_proto`` actually are ASCII strings, or am I entirely mistaken here? I’m pretty sure that DNS servers do not need to know about those labels to be able to handle them. I was not saying that we should hand the binary RRdata of the SRV record to the client; merely the _service label (even though you are right that _proto would be useful for future-proofing too) so that the client knows which protocol to use to connect (the RRdata of the record does not have the information). I’d just use the service and proto labels as identifiers which are already known to developers and which exactly describe what we want to express. But of course, this needs a change in the XEPs (but that’s trivial: @service, default it to ``_xmpps-client`` for isr, and ``_xmpp-client`` for sm; 100% backward compatible). kind regards, Jonas [1]: https://docs.zombofant.net/aioxmpp/devel/api/public/ node.html#aioxmpp.node.connect_xmlstream
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 _______________________________________________
