[Standards] Connection Type in XEP-0198 'location' (Direct-TLS vs STARTTLS)

Georg Lukas georg at op-co.de
Wed Dec 20 12:50:11 UTC 2017

* 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

> > 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

> 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.

|| http://op-co.de ++  GCS d--(++) s: a C+++ UL+++ !P L+++ !E W+++ N  ++
|| gpg: 0x962FD2DE ||  o? K- w---() O M V? PS+ PE-- Y++ PGP+ t+ 5 R+  ||
|| Ge0rG: euIRCnet ||  X(+++) tv+ b+(++) DI+++ D- G e++++ h- r++ y?   ||
++ IRCnet OFTC OPN ||_________________________________________________||
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171220/fbddc7eb/attachment.sig>

More information about the Standards mailing list