[Standards] Call for Experience: XEP-0368: SRV records for XMPP over TLS
jonas at wielicki.name
Tue Feb 11 16:44:00 UTC 2020
On Dienstag, 11. Februar 2020 17:29:47 CET Jonas Schäfer wrote:
> The XEP Editor would like to Call for Experience with XEP-0368 before
> presenting it to the Council for advancing it to Final status.
> During the Call for Experience, please answer the following questions:
> 1. What software has XEP-0368 implemented? Please note that the
> protocol must be implemented in at least two separate codebases (at
> least one of which must be free or open-source software) in order to
> advance from Draft to Final.
aioxmpp (LGPLv3) has an implementation . This implementation was created by
me and independently.
> 2. Have developers experienced any problems with the protocol as
> defined in XEP-0368?
Yes. The specification describes a new SRV record service label. The problem
is with the interaction of the various cases which can be expressed with SRV
records for xmpp-client and xmpps-client on the same domain (the same goes for
xmpp/s-server, but for simplicity, I’ll write my notes with *-client only).
First, a recap of what RFC 6120 says (abridged from Section 3.2 ):
1. Check if there is a _xmpp-client record for the domain. If there is:
1.1. If it points to the host ., stop connecting and inform user that
the domain does not offer XMPP.
1.2. Use normal SRV logic to pick connection targets
2. Look up A/AAAA records for the domain. Try to connect to the IP addresses
as found on port 5222 with STARTTLS.
XEP-0368 now brings _xmpps-client records into the mix. As currently written,
XEP-0368 specifies that if both record types are present, the targets are
mixed. So for example, on a domain with the following records:
_xmpp-client._tcp IN SRV 1 1 5222 xmpp.domain.example.
_xmpps-client._tcp IN SRV 1 1 5223 xmpp.domain.example.
there would be a fifty-fifty chance as to whether the client uses STARTTLS or
Direct TLS (assuming the client does not hard-code a preference).
This case is rather clear, although a non-standard use of SRV records.
However, the following cases need to be thought of and clearly defined in the
document to be compatible with RFC 6120:
- _xmpp-client set to `.`, _xmpps-client has valid entries
- _xmpps-client set to `.`, _xmpp-client has valid entries
- Neither are present (the only RFC 6120-compatible way here is to fall back
to STARTTLS on A/AAAA port 5222)
- _xmpp-client has no records, _xmpps-client has valid entries
(and the opposite case; I think those are implicitly covered by the mixing
I think the community needs to agree on what the correct behaviour is. We also
probably should have the discussion on whether the mixing of the records is
definitely and Final-ly okay. I know of at least one implementation which
refuses to do the mixing .
In case we drop the mixing, we need clear guidelines for operators to inform
them of the implications. Specifically, this may make clients attempt Direct
TLS on all SRV tiers (priorities) first and then fall back to (forced)
STARTTLS; this needs to be written down in the document, since it may have
unintended side effects if only a subset of the nodes of the tiers support
> 3. Is the text of XEP-0368 clear and unambiguous?
Except for the points above.
> Are more examples needed?
Would be good once we define the rules to the cases I mentioned above.
> Is the conformance language (MAY/SHOULD/MUST) appropriate?
I think so.
> Have developers found the text confusing at all?
Not confusing per se, but there certainly have been disagreements (see above).
> Please describe any suggestions you have for improving the text.
> If you have any comments about advancing XEP-0368 from Draft to Final,
> please provide them by the close of business on 2020-02-25. After the
> Call for Experience, this XEP might undergo revisions to address
> feedback received, after which it will be presented to the XMPP
> Council for voting to a status of Final.
> You can review the specification here:
> Please send all feedback to the standards at xmpp.org discussion list.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: This is a digitally signed message part.
More information about the Standards