* 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'. > > 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. > 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. Georg -- || 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 ||_________________________________________________||
signature.asc
Description: PGP signature
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: standards-unsubscr...@xmpp.org _______________________________________________
