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 <[email protected]> [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'
id='some-long-sm-id'
location='[2001:41D0:1:A49b::1]:9222'
how='starttls'
resume='true'/>
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,
Jonas
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Standards mailing list Info: https://mail.jabber.org/mailman/listinfo/standards Unsubscribe: [email protected] _______________________________________________
