On Sun, 30 Jun 2019 at 09:40, Jonas Schäfer <jo...@wielicki.name> wrote:
> On Samstag, 29. Juni 2019 23:32:41 CEST Dave Cridland wrote:
> > On Sat, 29 Jun 2019 at 16:56, Ralph Meijer <ral...@ik.nu> wrote:
> > > On June 29, 2019 4:32:15 PM GMT+02:00, "Jonas Schäfer" <
> > >
> > > jo...@wielicki.name> wrote:
> > > >Hi list,
> > > >
> > > >It is not clear to me how to interpret, in a library connecting to an
> > > >XMPP
> > > >service, a single SRV record for _xmpps-{client,server} which has `.`
> > > >as the
> > > >target.
> > > >
> > > >For RFC 6120 _xmpp-{client,server} records (note the missing `s`), a
> > > >`.`
> > > >indicates that the domain does not host an XMPP service at all, so
> > > >attempting
> > > >to form a connection should stop right there (most notably, no
> fallback
> > > >to
> > > >domainpart A/AAAA lookup).
> > > >
> > > >How should this be interpreted for XEP-0368? Should a `.` indicate "I
> > > >do not
> > > >speak direct TLS, but try _xmpp-client records"? Or should it
> indicate,
> > > >right
> > > >away, that there is no XMPP service on the domain?
> > >
> > > According to RFC 2782 it means the service xmpps-client is not
> available
> > > at this domain. So I think the answer should be the former. If there
> is a
> > > similar record for xmpp-client, though, you can't connect the regular
> way
> > > either. Maybe there's still another binding (BOSH, WebSocket) that
> could
> > > succeed, but
> > > defining all possible permutations is a bit much.
> >
> > I think:
> >
> > 1) A client ought to, if possible, send the two DNS queries in parallel.
> > 2) If this isn't the case, there's no "right" order.
> > 3) Therefore it'd be possible to obtain some records from _xmpp-client,
> but
> > afterward get a '.' from _xmpps-client.
> > 4) Therefore the only sensible interpretation is that it says direct TLS
> > (xmpps-client) is not supported, and says nothing about the traditional
> > method (xmpp-client).
> >
> > > >Whatever the consensus is, this should be written down in the XEP I
> > > >think.
> > >
> > > Agreed.
> >
> > I'm always for documenting things.
> >
> > May as well note here that the '.' target explicitly prevents use of the
> > fallback A/AAAA resolution.
>
> Thanks for your feedback folks.
>
> Here’s a proposal: https://github.com/xsf/xeps/pull/796
>
>
OK, two comments, which are essentially both my fault:
1) It's not A/AAAA fallback "as per RFC 6120", because we're talking about
a Direct TLS fallback. It should be per section... erm...
2) This document doesn't mention a A/AAAA fallback at all, and perhaps
that's right - do we ever want one with '368?
> Please comment on-list.
>
> kind regards,
> Jonas_______________________________________________
> Standards mailing list
> Info: https://mail.jabber.org/mailman/listinfo/standards
> Unsubscribe: standards-unsubscr...@xmpp.org
> _______________________________________________
>
_______________________________________________
Standards mailing list
Info: https://mail.jabber.org/mailman/listinfo/standards
Unsubscribe: standards-unsubscr...@xmpp.org
_______________________________________________
