mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-27 19:52:18 -05:00
Initial commit of Path MTU protoXEP
This commit is contained in:
Kim Alvefur
Jonas Schäfer
parent
7eaa3962a8
commit
958aad87ab
193
inbox/pathmtu.xml
Normal file
193
inbox/pathmtu.xml
Normal file
@ -0,0 +1,193 @@
|
|||||||
|
<?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>Stanza size limit discovery</title>
|
||||||
|
<abstract>This documents describes a mechanism for communicating stanza size limits across streams in order to help avoid reaching those limits.</abstract>
|
||||||
|
&LEGALNOTICE;
|
||||||
|
<number>xxxx</number>
|
||||||
|
<status>ProtoXEP</status>
|
||||||
|
<type>Standards Track</type>
|
||||||
|
<sig>Standards</sig>
|
||||||
|
<dependencies/>
|
||||||
|
<supersedes/>
|
||||||
|
<supersededby/>
|
||||||
|
<shortname>NOT_YET_ASSIGNED</shortname>
|
||||||
|
<author>
|
||||||
|
<firstname>Kim</firstname>
|
||||||
|
<surname>Alvefur</surname>
|
||||||
|
<email>zash@zash.se</email>
|
||||||
|
<jid>zash@zash.se</jid>
|
||||||
|
</author>
|
||||||
|
<revision>
|
||||||
|
<version>0.0.1</version>
|
||||||
|
<date>2021-08-20</date>
|
||||||
|
<initials>ka</initials>
|
||||||
|
<remark>
|
||||||
|
<p>Early draft</p>
|
||||||
|
</remark>
|
||||||
|
</revision>
|
||||||
|
<revision>
|
||||||
|
<version>nil</version>
|
||||||
|
<date>2021-08-25</date>
|
||||||
|
<initials>ka</initials>
|
||||||
|
<remark>
|
||||||
|
<p>more work</p>
|
||||||
|
</remark>
|
||||||
|
</revision>
|
||||||
|
<revision>
|
||||||
|
<version>nil</version>
|
||||||
|
<date>2021-08-28</date>
|
||||||
|
<initials>ka</initials>
|
||||||
|
<remark>
|
||||||
|
<p>more words</p>
|
||||||
|
</remark>
|
||||||
|
</revision>
|
||||||
|
</header>
|
||||||
|
<section1 topic="Introduction" anchor="intro">
|
||||||
|
|
||||||
|
<p>This documents describes a mechanism for communicating the stanza size
|
||||||
|
limit that is in effect on a particular stream, in order to allow the
|
||||||
|
other party to avoid reaching those limits.</p>
|
||||||
|
|
||||||
|
<section2 topic="Problem statement" anchor="problem-statement">
|
||||||
|
|
||||||
|
<p>When stanza size limits have been deployed, very often this leads to
|
||||||
|
problems with large stanzas causing connection outages, most often
|
||||||
|
vCards and Avatar stanzas.</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>
|
||||||
|
|
||||||
|
<p>Especially vCard and Avatar stanzas may be very large and sometimes
|
||||||
|
exceed the stanza size limit imposed.</p>
|
||||||
|
|
||||||
|
</section2></section1><section1 topic="Requirements" anchor="reqs">
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li>Enable discovery of the stanza size limit in use on a stream.</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
<section2 topic="TODO" anchor="todo">
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li>bi-directional?</li>
|
||||||
|
<li>disco too?</li>
|
||||||
|
<li>some sort of path mtu discovery method?</li>
|
||||||
|
<li>error condition?</li>
|
||||||
|
<li>rewrite large iq-result to error?</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
</section2></section1><section1 topic="Glossary" anchor="glossary">
|
||||||
|
|
||||||
|
<p>OPTIONAL.</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="Use Cases" anchor="usecases">
|
||||||
|
|
||||||
|
<ul>
|
||||||
|
<li>An XMPP client could attempt to apply more compression if it sees
|
||||||
|
that an avatar it is about to upload would be too large.</li>
|
||||||
|
<li>A PubSub server could limit the number of items in an <tt><items/></tt>
|
||||||
|
query to ensure it can be delivered.</li>
|
||||||
|
</ul>
|
||||||
|
|
||||||
|
</section1><section1 topic="Business Rules" anchor="rules">
|
||||||
|
|
||||||
|
<p>If after serialization to XML a stanza is too large, like, don’t send
|
||||||
|
it. Synthesize an error condition, most likely a (modify,
|
||||||
|
policy-violation), and pretend the remote entity replied with this.</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="Implementation Notes" anchor="impl">
|
||||||
|
|
||||||
|
<p>Something about margins, due to variations in XML serialization, added
|
||||||
|
attributes (e.g. the <tt>from</tt> attribute stamped by servers) or elements
|
||||||
|
(delay tags)</p>
|
||||||
|
|
||||||
|
<p>Because the stanza size limit is known ahead of time, entities can check
|
||||||
|
this against stanzas they are about to send and take appropriate action,
|
||||||
|
such as preemptively pretending that the stanza was rejected by the
|
||||||
|
receiving entity.</p>
|
||||||
|
|
||||||
|
<p>A client could for example try to apply more compression to an avatar or
|
||||||
|
ask the user to select a smaller picture.</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="Accessibility Considerations" anchor="access">
|
||||||
|
|
||||||
|
<p>OPTIONAL.</p>
|
||||||
|
|
||||||
|
<p>Not relevant?</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="Internationalization Considerations" anchor="i18n">
|
||||||
|
|
||||||
|
<p>OPTIONAL.</p>
|
||||||
|
|
||||||
|
<p>Not relevant?</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="Determining support" anchor="determining-support">
|
||||||
|
|
||||||
|
<p>The responding entity advertises the stanza size limit it enforces
|
||||||
|
by including it as an integer in a stream feature element
|
||||||
|
<tt>stanza-size-limit</tt> in the namespace <tt>urn:xmpp:tmp:TBD</tt>. An example of
|
||||||
|
stream features prior to authentication follows:</p>
|
||||||
|
|
||||||
|
<example><![CDATA[<stream:features>
|
||||||
|
<mechanisms xmlns="urn:ietf:params:xml:ns:xmpp-sasl">
|
||||||
|
<mechanism>SCRAM-SHA-1</mechanism>
|
||||||
|
<mechanism>PLAIN</mechanism>
|
||||||
|
</mechanisms>
|
||||||
|
<stanza-size-limit xmlns="urn:xmpp:tmp:TBD">10000</stanza-size-limit>
|
||||||
|
</stream:features>]]></example>
|
||||||
|
|
||||||
|
<p>Entities may wish to have hire limits after authentication and would
|
||||||
|
advertise it the same way after the stream restart:</p>
|
||||||
|
|
||||||
|
<example><![CDATA[<stream:features>
|
||||||
|
<bind xmlns="urn:ietf:params:xml:ns:xmpp-bind">
|
||||||
|
<required/>
|
||||||
|
</bind>
|
||||||
|
<stanza-size-limit xmlns="urn:xmpp:tmp:TBD">262144</stanza-size-limit>
|
||||||
|
</stream:features>]]></example>
|
||||||
|
|
||||||
|
</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>
|
||||||
|
|
||||||
|
<p>Also see https://xmpp.org/rfcs/rfc6120.html#rfc.section.13.12</p>
|
||||||
|
|
||||||
|
<p>TBD Recommendations for limits?</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="IANA Considerations" anchor="iana">
|
||||||
|
|
||||||
|
<p>None.</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="XMPP Registrar Considerations" anchor="registrar">
|
||||||
|
|
||||||
|
<p>Need the stream feature registered.</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="Design Considerations" anchor="design">
|
||||||
|
|
||||||
|
<p>RECOMMENDED.</p>
|
||||||
|
|
||||||
|
<p>Design? I just typed words and code into my computer!</p>
|
||||||
|
|
||||||
|
</section1><section1 topic="XML Schema" anchor="schema">
|
||||||
|
|
||||||
|
<p>REQUIRED for protocol specifications.</p>
|
||||||
|
|
||||||
|
<code><![CDATA[type: integer
|
||||||
|
xml:
|
||||||
|
name: stanza-size-limit
|
||||||
|
namespace: urn:xmpp:tmp:TBD]]></code>
|
||||||
|
</section1>
|
||||||
|
</xep>
|
||||||
|
|
||||||
Loading…
Reference in New Issue
Block a user