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