[Standards] Council Minutes 2019-07-10

Travis Burtrum travis at burtrum.org
Fri Jul 19 05:36:25 UTC 2019


Hi all,

On 7/17/19 9:57 AM, Tedd Sterr wrote:

> *3b) PR #796 - XEP-0368: clarify what happens when a `.` target is
> published* - https://github.com/xsf/xeps/pull/796
> Jonas: +1
> Link: +1 (definitely!)
> Georg: +1 (this is just a clarification of RFC 2782)
> Dave: [pending]
> Kev: [pending]

Sorry I missed the vote on this but I could not disagree more on half of
this change.

I will review the 2 halves separately here.

Part 1:

> If the _xmpps-client (or _xmpps-server) target is set to . (dot), this
indicates as per RFC 2782 that the service is not provided for the given
domain. In this context, this means that Direct TLS is not supported. In
this case, the initiating party SHOULD look up _xmpp-client (or
_xmpp-server) records.

Part 1 is, as Georg put it "just a clarification of RFC 2782", I have no
problem with this.

Part 2:

> The initiating party MUST NOT perform A/AAAA fallback as per RFC 6120
(since the service provider has already indicated that the SRV protocol
is supported).

Part 2 adds new MUST NOT normative language to a Draft XEP that simply
didn't exist before. Also in my opinion this language is just wrong, and
if I were to make a change to the XEP here it would be the opposite,
something like:

> If the initiating party cannot connect via either SRV record, it
SHOULD perform A/AAAA fallback to port(s) of it's choice (perhaps 443,
5223, etc) because, in the absence of DNSSEC, SRV records cannot be trusted.

I went ahead and made a pull request with this text here:

https://github.com/xsf/xeps/pull/801

I also think just adding Part 1 and nothing else would be equally fine,
allowing client/server developers decide on their own if or how to
fallback, in practice they will anyway regardless.

Thanks much,
Travis


More information about the Standards mailing list