1
0
mirror of https://github.com/moparisthebest/xeps synced 2024-11-22 01:02:17 -05:00
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2591 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2008-12-19 22:57:09 +00:00
parent 778a161f1d
commit 8e11aa46a5

View File

@ -21,6 +21,12 @@
<supersededby/> <supersededby/>
<shortname>N/A</shortname> <shortname>N/A</shortname>
&stpeter; &stpeter;
<revision>
<version>0.2</version>
<date>2008-12-19</date>
<initials>psa</initials>
<remark><p>Incorporated Last Call comments: removed paragraph about compression, added paragraph about rate limiting in message or presence amplifiers, corrected simultaneous connections error per rfc3920bis.</p></remark>
</revision>
<revision> <revision>
<version>0.2</version> <version>0.2</version>
<date>2007-07-10</date> <date>2007-07-10</date>
@ -157,6 +163,7 @@
</section2> </section2>
<section2 topic='Service Restrictions' anchor='rec-services'> <section2 topic='Service Restrictions' anchor='rec-services'>
<p>An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See <cite>XEP-0045</cite> regarding methods of banning users from multi-user chat rooms and <cite>XEP-0060</cite> regarding methods for prohibiting users from interacting with publish-subscribe nodes.)</p> <p>An implementation of a service that enables traffic amplification (e.g., multi-user chat or publish-subscribe) SHOULD enable an administrator of that service to limit (based on JabberID or other characteristics) what entities may send information through the service. (See <cite>XEP-0045</cite> regarding methods of banning users from multi-user chat rooms and <cite>XEP-0060</cite> regarding methods for prohibiting users from interacting with publish-subscribe nodes.)</p>
<p>In fact, the "session manager" of an XMPP presence server also acts as just such an amplifier, since presence information is broadcast to all subscribers. Any such service SHOULD enable an administrator to limit the number of stanzas sent through the service in any given period of time (presence changes in a session manager, presence changes or messages in a chatroom, published items in a pubsub service).</p>
</section2> </section2>
</section1> </section1>
<section1 topic='Implementation Considerations' anchor='impl'> <section1 topic='Implementation Considerations' anchor='impl'>
@ -164,7 +171,6 @@
<ul> <ul>
<li>Less strict limits for server administrators compared to entities associated with registered accounts, and for entities associated with registered accounts compared to anonymous entities.</li> <li>Less strict limits for server administrators compared to entities associated with registered accounts, and for entities associated with registered accounts compared to anonymous entities.</li>
<li>Less strict limits for entities that authenticate via strong authentication methods (e.g., TLS + SASL EXTERNAL) compared to entities that authenticate via weaker authentication methods (e.g., TLS + SASL PLAIN or server dialback).</li> <li>Less strict limits for entities that authenticate via strong authentication methods (e.g., TLS + SASL EXTERNAL) compared to entities that authenticate via weaker authentication methods (e.g., TLS + SASL PLAIN or server dialback).</li>
<li>Less strict limits for entities that use stream compression (via the TLS compression bit or &xep0138;) compared to entities that do not use stream compression.</li>
<li>Less strict limits for connections from known IP addresses.</li> <li>Less strict limits for connections from known IP addresses.</li>
<li>Less strict limits for connections made via the TCP binding compared to connections made via the HTTP binding.</li> <li>Less strict limits for connections made via the TCP binding compared to connections made via the HTTP binding.</li>
</ul> </ul>