moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-21 16:55:07 -05:00
Code Issues Releases Wiki Activity

XEP-0368: Version 0.1.2 Implement more last call comments, editorial changes, mixing SRV records is now SHOULD

Browse Source
This commit is contained in:
Travis Burtrum 2017-02-16 00:52:50 -05:00 committed by Sam Whited
parent bbf8cac8c0
commit 856c7427d6
2 changed files with 9 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
xep-0368.xml
View File

@ -29,6 +29,12 @@
<email>travis@burtrum.org</email>
<jid>travis@burtrum.org</jid>
</author>
<revision>
<version>0.1.2</version>
<date>2017-02-15</date>
<initials>tjb</initials>
<remark><p>Implement more last call comments, editorial changes, mixing SRV records is now SHOULD.</p></remark>
</revision>
<revision>
<version>0.1.1</version>
<date>2017-02-06</date>
@ -55,7 +61,7 @@
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>&xmppcore; specifies the use of xmpp-client/xmpp-server SRV records as the method of discovering how to connect to an XMPP server. This XEP extends that to include new xmpps-client/xmpps-server SRV records pointing to direct TLS ports and combine priorities and weights as if they were a single SRV record. Applied to both xmpps-client and xmpps-server SRV records, this provides the opportunity to connect to XMPP servers with at least equal and perhaps increased security and privacy over using STARTTLS. It also provides an easy way for clients to bypass restrictive firewalls that only allow HTTPS, and for servers to host multiple protocols/services on a single port.</p>
<p>&xmppcore; specifies the use of xmpp-client/xmpp-server SRV records as the method of discovering how to connect to an XMPP server. This XEP extends that to include new xmpps-client/xmpps-server SRV records pointing to direct TLS ports and combine priorities and weights as if they were a single SRV record similar to &rfc6186;. It also provides an easy way for clients to bypass restrictive firewalls that only allow HTTPS, for servers to host multiple protocols/services on a single port, and for servers and clients to take advantage of less round trips and existing direct TLS loadbalancers.</p>
</section1>
<section1 topic='Glossary' anchor='glossary'>
<dl>
@ -74,7 +80,7 @@
]]></code>
<p><cite>XMPP Core</cite> defines SRV records only where 'service' is 'xmpp-client' and 'xmpp-server'. This document specifies to additionally look up records where 'service' is 'xmpps-client' and 'xmpps-server'. This document specifies that the following additional rules apply:</p>
<ol>
<li>Treat both 'xmpp-' and 'xmpps-' records as the same record with regard to connection order as specified by <cite>RFC 2782</cite>, in that all priorities and weights are mixed. (so the server operator can decide if they would rather clients connect to tcp with STARTTLS or just with TLS directly)</li>
<li>Both 'xmpp-' and 'xmpps-' records SHOULD be treated as the same record with regard to connection order as specified by <cite>RFC 2782</cite>, in that all priorities and weights are mixed. This enables the server operator to decide if they would rather clients connect with STARTTLS or direct TLS. However, clients MAY choose to prefer one type of connection over the other.</li>
<li>Where 'service' starts with 'xmpps-' the client or server MUST connect with direct TLS enabled.</li>
<li>Where 'service' starts with 'xmpp-' the client or server MUST NOT connect with direct TLS enabled, connection method is unchanged from <cite>XMPP Core</cite>.</li>
<li>TLS certificates MUST be validated the same way as for STARTTLS. (i.e., as specified in <cite>XMPP Core</cite>).</li>

1
xep.ent
View File

@ -647,6 +647,7 @@ THE SOFTWARE.
<!ENTITY rfc6149 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6149'>RFC 6149</link></span> <note>RFC 6149: MD2 to Historic Status &lt;<link url='http://tools.ietf.org/html/rfc6149'>http://tools.ietf.org/html/rfc6149</link>&gt;.</note>" >
<!ENTITY rfc6150 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6150'>RFC 6150</link></span> <note>RFC 6150: MD4 to Historic Status &lt;<link url='http://tools.ietf.org/html/rfc6150'>http://tools.ietf.org/html/rfc6150</link>&gt;.</note>" >
<!ENTITY rfc6151 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6151'>RFC 6151</link></span> <note>RFC 6151: Updated Security Considerations for the MD5 Message-Digest and the HMAC-MD5 Algorithms &lt;<link url='http://tools.ietf.org/html/rfc6151'>http://tools.ietf.org/html/rfc6151</link>&gt;.</note>" >
<!ENTITY rfc6186 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6186'>RFC 6186</link></span> <note>RFC 6186: Use of SRV Records for Locating Email Submission/Access Services &lt;<link url='http://tools.ietf.org/html/rfc6186'>http://tools.ietf.org/html/rfc6186</link>&gt;.</note>" >
<!ENTITY rfc6189 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6189'>RFC 6189</link></span> <note>RFC 6189: ZRTP: Media Path Key Agreement for Unicast Secure RTP &lt;<link url='http://tools.ietf.org/html/rfc6189'>http://tools.ietf.org/html/rfc6189</link>&gt;.</note>" >
<!ENTITY rfc6194 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6194'>RFC 6194</link></span> <note>RFC 6194: Updated Security Considerations for the SHA-0 and SHA-1 Message-Digest Algorithms &lt;<link url='http://tools.ietf.org/html/rfc6194'>http://tools.ietf.org/html/rfc6194</link>&gt;.</note>" >
<!ENTITY rfc6234 "<span class='ref'><link url='http://tools.ietf.org/html/rfc6234'>RFC 6234</link></span> <note>RFC 6234: US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF) &lt;<link url='http://tools.ietf.org/html/rfc6234'>http://tools.ietf.org/html/rfc6234</link>&gt;.</note>" >