moparisthebest/xeps
1
0
Fork 0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-23 09:42:20 -05:00
Code Issues Releases Wiki Activity

Merge branch 'protoxep-sla' into premerge

Browse Source
This commit is contained in:
Jonas Schäfer 2022-12-20 19:31:53 +01:00
commit 40e954b499
2 changed files with 129 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

126
inbox/xep-sla.xml Normal file
View File

@ -0,0 +1,126 @@
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Stream Limits Advertisement</title>
<abstract>This specification defines a way for an XMPP entity to announce the limits it will enforce for data received on a stream.</abstract>
&LEGALNOTICE;
<number>xxxx</number>
<status>ProtoXEP</status>
<type>Standards Track</type>
<sig>Standards</sig>
<approver>Council</approver>
<dependencies>
<spec>XMPP Core</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>sla</shortname>
<author>
<firstname>Kim</firstname>
<surname>Alvefur</surname>
<email>zash@zash.se</email>
<jid>zash@zash.se</jid>
</author>
&mwild;
<revision>
<version>0.0.1</version>
<date>2022-10-20</date>
<initials>ka, mw</initials>
<remark><p>First draft.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>This documents describes a mechanism for communicating limits, such as stanza size limits that is in effect on a particular stream, in order to allow the sending party to avoid reaching those limits.</p>
<section2 topic='Problem statement' anchor='intro-problem'>
<p>Where stanza size limits have been deployed, very often this leads to problems with large stanzas causing connection outages, most often &xep0084; and &xep0053; result stanzas, which can be very large due to embedded images.</p>
<p>If stanza size limit violations are met with stream errors then this may lead to temporary connection outage, which may a few seconds to recover from.</p>
</section2>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<ul>
<li>Enable discovery of the stanza size limit in use on a stream.</li>
<li>Support for bi-directional streams.</li>
</ul>
<p>These requirements will enable XMPP clients and servers to adapt data they generate, such that it will fit within the limits required by the recipient, or reject overly large stanzas early, rather than following a trial-and-error approach.</p>
</section1>
<section1 topic='Use Cases' anchor='usecases'>
<section2 topic='Server advertises limits to connecting entity' anchor='advertise'>
<p>For any XMPP stream, there is an "initiating entity" (a client or server) and a "responding entity" that they are connecting to. The responding entity advertises its limits in the &lt;stream:features/> element that it sends at the start of the stream.</p>
<p>The limits are enclosed in a &lt;limits/> element qualified by the 'urn:xmpp:stream-limits:0' namespace. This element SHOULD contain the following child elements:</p>
<dl>
<di>
<dt>&lt;max-bytes/></dt>
<dd>Contains an integer representing the maximum size of any first-level stream elements (including stanzas), in bytes the announcing entity is willing to accept. Guidance on acceptable limits is provided in &rfc6120; section 13.12.</dd>
</di>
<di>
<dt>&lt;idle-seconds/></dt>
<dd>Contains an integer representing the number of seconds without any traffic from the iniating entity after which the server may consider the stream idle, and either perform liveness checks (using e.g. &xep0198; or &xep0199;) or terminate the stream. Guidance on handling idle connections is provided in &rfc6120; section 4.6.</dd>
</di>
</dl>
<example caption='Advertising limits to connecting entity'><![CDATA[
<stream:features>
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
<mechanism>SCRAM-SHA-1</mechanism>
<mechanism>PLAIN</mechanism>
</mechanisms>
<limits xmlns="urn:xmpp:stream-limits:0">
<max-bytes>10000</max-bytes>
<idle-seconds>1800</idle-seconds>
</limits>
</stream:features>
]]></example>
</section2>
<section2 topic='Connecting server announces limits on bidirectional stream' anchor='advertise-bidi'>
<p>Servers using &xep0288; to establish a bidirectional stream with another server do not get an opportunity to send &lt;stream:features/> to the responding entity. For a server to advertise the limits about what it is willing to accept on such a stream, the &lt;limits/> element can be included in the &lt;bidi/> element.</p>
<example caption='Advertising limits to responding entity over bidirectional stream'><![CDATA[
<bidi xmlns='urn:xmpp:bidi'>
<limits xmlns="urn:xmpp:stream-limits:0">
<max-bytes>10000</max-bytes>
<idle-seconds>1800</idle-seconds>
</limits>
</bidi>
]]></example>
</section2>
</section1>
<section1 topic='Business Rules' anchor='rules'>
<p>If, after serialization, a stanza exceeds the limits that have been advertised on a stream, it SHOULD NOT be sent on that stream. Instead, a server SHOULD return an error to the sender. Such an error SHOULD contain the &lt;policy-violation/> error condition, and SHOULD NOT contain a 'by' attribute (as the policy being violated is not the current entity's). A &lt;text/> may also be included, explaining the limit that would be exceeded.</p>
<p>It is acceptable for the limits on a stream to change whenever new stream features are announced - such as before and after authentication of the connecting entity.</p>
</section1>
<section1 topic='Implementation Notes' anchor='impl'>
<p>OPTIONAL.</p>
</section1>
<section1 topic='Accessibility Considerations' anchor='access'>
<p>OPTIONAL.</p>
</section1>
<section1 topic='Internationalization Considerations' anchor='i18n'>
<p>OPTIONAL.</p>
</section1>
<section1 topic='Security Considerations' anchor='security'>
<p>REQUIRED.</p>
<p>Very large stanzas may incur memory and processing costs on the receiving entity. Advertising the actual limits could inform an attacker of how large a stanza to construct in order to maximize e.g. DoS effectiveness. Best combined with network level rate limits on raw bytes.</p>
</section1>
<section1 topic='IANA Considerations' anchor='iana'>
<p>None.</p>
</section1>
<section1 topic='XMPP Registrar Considerations' anchor='registrar'>
<p>This specification defines the following namespace:</p>
<ul>
<li>urn:xmpp:stream-limits:0</li>
</ul>
<p>Also, the following stream feature:</p>
<ul>
<li><code>&lt;limits xmlns='urn:xmpp:stream-limits:0'/></code></li>
</ul>
</section1>
<section1 topic='Design Considerations' anchor='design'>
<p>The ability for a client to announce limits on what it will receive on a client-to-server stream is deliberately not provided by this specification. This vastly simplifies discovery of the maximum limits between any two JIDs, and it avoids situations where the server is unable to deliver incoming stanzas to some or all of an account's connected clients. Clients will already be protected from denial-of-service through excessive stanza sizes due to the server's own limits.</p>
</section1>
<section1 topic='XML Schema' anchor='schema'>
<p>TBD.</p>
</section1>
</xep>

6
tools/validate-xep0001-conformance.sh
View File

@ -61,10 +61,10 @@ else
validation_result=1 validation_result=1
fi fi
# 3.2 That the /xep/header/number/text() (XPath) is literally XXXX # 3.2 That the /xep/header/number/text() (XPath) is literally XXXX or xxxx
if [ "$header_number" = "XXXX" ] if [ "$header_number" = "XXXX" ] || [ "$header_number" = "xxxx" ]
then then
echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX'." echo "[PASS] XPATH value /xep/header/number/text() ('$header_status') equals 'XXXX' (case insensitive)."
else else
echo "[FAIL] XPATH value /xep/header/number/text() ('$header_status') does not equal 'XXXX' (but should)." echo "[FAIL] XPATH value /xep/header/number/text() ('$header_status') does not equal 'XXXX' (but should)."
validation_result=1 validation_result=1