From b5e93e8e572690e5fe8f9006e52a1888502c8f4a Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= <j.wielicki@sotecware.net>
Date: Sun, 30 Jun 2019 10:37:13 +0200
Subject: [PATCH 1/2] XEP-0368: clarify what happens when a `.` target is
 published

This is proposal to formalise the results of the [list discussion][1].

   [1]: https://mail.jabber.org/pipermail/standards/2019-June/036235.html
---
 xep-0368.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/xep-0368.xml b/xep-0368.xml
index 62eb2d2a..f5e84ac9 100644
--- a/xep-0368.xml
+++ b/xep-0368.xml
@@ -103,6 +103,7 @@
 <section1 topic='Implementation Notes' anchor='impl'>
   <p>The only overhead is the single additional SRV lookup. All clients that support STARTTLS already have support for direct TLS.</p>
   <p>Server operators should not expect multiplexing (via ALPN) to work in all scenarios and therefore should provide additional SRV record(s) that do not require multiplexing (either standard STARTTLS or dedicated direct XMPP-over-TLS).  This is a result of relying on ALPN for multiplexing, where ALPN might not be supported by all devices or may be disabled by a user due to privacy reasons.</p>
+  <p>If the <tt>_xmpps-client</tt> (or <tt>_xmpps-server</tt>) target is set to <tt>.</tt> (dot), this indicates as per &rfc2782; 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 <tt>_xmpp-client</tt> (or <tt>_xmpp-server</tt>) records. The initiating party MUST NOT perform A/AAAA fallback as per &rfc6120; (since the service provider has already indicated that the SRV protocol is supported).</p>
 </section1>
 <section1 topic='Security Considerations' anchor='security'>
     <p>Direct TLS provides AT LEAST the same level of security as STARTTLS, and more privacy without ALPN as using STARTTLS leaks that the underlying protocol is XMPP, while any direct TLS stream should be indistinguishable from any other direct TLS stream. Direct TLS provides more security than STARTTLS if &rfc7590; is not followed, as it isn't subject to STARTTLS stripping. All security setup and certificate validation code SHOULD be shared between the STARTTLS and direct TLS logic as well. All SRV-based connection methods are subject to DNS modification/stripping/spoofing of SRV records in the absence of DNSSEC.</p>

From 95a7245a9652e09cebf09f3e2fb0ae5579a0d466 Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jonas=20Sch=C3=A4fer?= <j.wielicki@sotecware.net>
Date: Tue, 20 Aug 2019 18:07:57 +0200
Subject: [PATCH 2/2] XEP-0368: add revision block

---
 xep-0368.xml | 6 ++++++
 1 file changed, 6 insertions(+)

diff --git a/xep-0368.xml b/xep-0368.xml
index f5e84ac9..1bed5eed 100644
--- a/xep-0368.xml
+++ b/xep-0368.xml
@@ -29,6 +29,12 @@
     <email>travis@burtrum.org</email>
     <jid>travis@burtrum.org</jid>
   </author>
+  <revision>
+    <version>1.1.0</version>
+    <date>2019-08-20</date>
+    <initials>jsc</initials>
+    <remark><p>Describe how to fall back if _xmpps-server/_xmpps-client records cannot be found.</p></remark>
+  </revision>
   <revision>
     <version>1.0.0</version>
     <date>2017-03-09</date>