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

Jonas Wielicki jonas at wielicki.name
Wed Dec 20 13:56:58 UTC 2017

On Mittwoch, 20. Dezember 2017 14:38:08 CET Jonas Wielicki wrote:
> On Mittwoch, 20. Dezember 2017 13:50:11 CET Georg Lukas wrote:
> > * Jonas Wielicki <jonas at wielicki.name> [2017-12-20 13:06]:
> > > 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).

I’ve been told that this is still not clear, so let me try to re-phrase. What 
I mean is that it would be easy and backward-compatible to add fields to the 
respective elements which express how the client shall reconnect (Direct-TLS, 
STARTTLS, …). For example (to build on the example in XEP-0198):

<enabled xmlns='urn:xmpp:sm:3'

How we call @how and which values we use doesn’t really matter. I was 
suggesting to use the values defined for SRV records  (xmpp-server, xmpp-
client, …) because those are already known to developers (familiarity and 
such), but expressed myself badly, making people think that I meant to 
actually use the SRV Record *data* (the right-hand side in common ASCII 
representations), which is nonsense and not useful.

After further discussion, using the SRV record labels doesn’t even suffice, 
because they don’t cover BOSH or websockets. So we’d have to define values, 
but that’s bikeshedding (bosh, websocket, xmpp, xmpps come to mind).

As for compatibility:

* if a client does not suppotr @how, but @location, it would try to connect 
with the potentially wrong method to @location, failing, and thus making 
stream resumption possibly fail. That’s not super-great, but I think this is 
the best we can do (if we namespace-bumped SM so that the attribute *and all 
of its possible values* were mandatory-to-implement, we would still exclude 
SM:3 clients).

* for the case where a server does not emit @how, we would define the default 
of "xmpp" (STARTTLS).

The same (but with "xmpps" default) would apply to ISR.

I hope this is clearer :).

kind regards,
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.jabber.org/pipermail/standards/attachments/20171220/4ff89112/attachment.sig>

More information about the Standards mailing list