[Standards] Connection Type in XEP-0198 'location' (Direct-TLS vs STARTTLS)
jonas at wielicki.name
Wed Dec 20 13:38:08 UTC 2017
On Mittwoch, 20. Dezember 2017 13:50:11 CET Georg Lukas wrote:
> * Jonas Wielicki <jonas at 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
Okay. That’s a bit less worrying, but the same argument I put below applies
> > > 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
Okay, so this may just be me. But in aioxmpp, there is just a
connect_xmlstream function , 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
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%
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards