mirror of
https://github.com/moparisthebest/xeps
synced 2024-11-21 16:55:07 -05:00
renamed XEP-0158 per Council discussion
git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2091 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
parent
e0ffbb0d4e
commit
9e1ae31e19
@ -6,7 +6,7 @@
|
||||
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
|
||||
<xep>
|
||||
<header>
|
||||
<title>Robot Challenges</title>
|
||||
<title>CAPTCHA Forms</title>
|
||||
<abstract>This document specifies an XMPP protocol extension that entities may use to discover whether the sender of an XML stanza is a human user or a robot.</abstract>
|
||||
&LEGALNOTICE;
|
||||
<number>0158</number>
|
||||
@ -655,7 +655,7 @@
|
||||
<section1 topic='Discontinuation Policy' anchor='stop'>
|
||||
<p>It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see <cite>XEP-0161</cite> and &xep0205;).</p>
|
||||
<p>It is expected that this protocol will be an important and successful tool for discouraging abusive traffic. However, much of its success is dependent on the quality of the CAPTCHAs and other puzzles employed by a particular implementation.</p>
|
||||
<p>The administrator of an application that functions as a challenger SHOULD discontinue the use of Robot Challenges under the following circumstances:</p>
|
||||
<p>The administrator of an application that functions as a challenger SHOULD discontinue the use of CAPTCHA forms under the following circumstances:</p>
|
||||
<ul>
|
||||
<li>If he realises that the challenger's challenges are largely ineffective in combating abusive traffic, and that the reduction in abuse does not compensate for the inconvenience to humans of responding to the challenger's challenges.</li>
|
||||
<li>If other, <em>more transparent</em>, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against abusive traffic.</li>
|
||||
|
@ -87,7 +87,7 @@
|
||||
</section2>
|
||||
<section2 topic='Note on Spim Recognition' anchor='intro-recognition'>
|
||||
<p>The various spim recognition procedures that may be employed by the server are beyond the scope of this document. No single measure can differentiate all spim perfectly. It is RECOMMENDED that servers implement a combination of complementary spim recognition techniques (and other anti-spim techniques <note>Other examples of anti-spim policies and protocols include: requiring a user to pass a robot challenge before registering a new account, invite-only and/or out-of-band user account registration, providing a standard protocol for reporting spim to both the servers involved, server-to-server connection dialback, karma (client-to-server and server-to-server), legal agreements not to send spim during user account registration, and IP blocking.</note>).</p>
|
||||
<p>For example, a server could employ traffic and reputation analysis to filter the majority of spim, and use <cite>Robot Challenges</cite> to identify the remainder (feeding what it learns back to the traffic and reputation analysis).</p>
|
||||
<p>For example, a server could employ traffic and reputation analysis to filter the majority of spim, and use <cite>CAPTCHA Forms</cite> to identify the remainder (feeding what it learns back to the traffic and reputation analysis).</p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
@ -137,7 +137,7 @@
|
||||
<li>The server MAY allow or deny delivery of the stanza at any time (for reasons not defined in this document).</li>
|
||||
</ul>
|
||||
<p>Once delivery of a stanza has been delayed for an implementation-specific length of time, or an implementation-specific number of stanzas from the same sender (or same sending server) are being delayed, the server SHOULD deny delivery of the stanza without informing the sender.</p>
|
||||
<p>A good example of a delayed spim recognition procedure is when servers use the <cite>Robot Challenges</cite> protocol to confirm whether or not a client is a spim robot before denying or allowing the delivery of a stanza from a <em>new correspondent</em>. <note>The very occasional inconvenience of responding to a challenge is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.</note> <note>If a human user fails such a robot challenge then his client SHOULD give him the option to resend the stanza immediately.</note></p>
|
||||
<p>A good example of a delayed spim recognition procedure is when servers use the <cite>CAPTCHA Forms</cite> protocol to confirm whether or not a client is a spim robot before denying or allowing the delivery of a stanza from a <em>new correspondent</em>. <note>The very occasional inconvenience of responding to a challenge is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.</note> <note>If a human user fails such a robot challenge then his client SHOULD give him the option to resend the stanza immediately.</note></p>
|
||||
</section2>
|
||||
</section1>
|
||||
|
||||
@ -148,7 +148,7 @@
|
||||
<p>The client SHOULD use the 'subscription' type to exclude all JIDs on the user's roster from spim blocking (see the items with order 20, 30 and 40 in the example below).</p>
|
||||
</section3>
|
||||
<section3 topic='Transports' anchor='privacy-exempt-transports'>
|
||||
<p>At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive spim recognition techniques (like <cite>Robot Challenges</cite>). So, if its server uses interactive techniques, the client MAY use the 'jid' type to ensure its server does not block stanzas arriving from the transports the user has registered with (see the item with order 50 in the example below).</p>
|
||||
<p>At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive spim recognition techniques (like <cite>CAPTCHA Forms</cite>). So, if its server uses interactive techniques, the client MAY use the 'jid' type to ensure its server does not block stanzas arriving from the transports the user has registered with (see the item with order 50 in the example below).</p>
|
||||
</section3>
|
||||
<section3 topic='Users of Trusted Servers' anchor='privacy-exempt-servers'>
|
||||
<p>If a user believes spim will not be sent by users of a particular server (e.g. the user's own corporate server), then the client MAY use the 'jid' type to exclude all these users from spim blocking (see the item with order 60 in the example below).</p>
|
||||
@ -188,7 +188,7 @@
|
||||
</section2>
|
||||
|
||||
<section2 topic='Exempting Individual Users from Spim Blocking' anchor='legacy'>
|
||||
<p>No spim recognition techniques are perfect. Senders are sometimes falsely identified as spim bots. (For example, when a server sends <cite>Robot Challenges</cite>, but the client does not support that protocol.)</p>
|
||||
<p>No spim recognition techniques are perfect. Senders are sometimes falsely identified as spim bots. (For example, when a server sends <cite>CAPTCHA Forms</cite>, but the client does not support that protocol.)</p>
|
||||
<p>In these cases the user MAY ask out-of-band the person he is trying to communicate with to allow communications in one of the following ways:</p>
|
||||
<ul>
|
||||
<li>simply send him a message, so her server adds him to her correspondents list</li>
|
||||
|
2
xep.ent
2
xep.ent
@ -911,7 +911,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates</link></span> <note>
|
||||
<!ENTITY xep0155 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0155.html'>Stanza Session Negotiation</link></span> <note>XEP-0155: Stanza Session Negotiation <<link url='http://www.xmpp.org/extensions/xep-0155.html'>http://www.xmpp.org/extensions/xep-0155.html</link>>.</note>" >
|
||||
<!ENTITY xep0156 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0156.html'>Discovering Alternative XMPP Connection Methods</link></span> <note>XEP-0156: Discovering Alternative XMPP Connection Methods <<link url='http://www.xmpp.org/extensions/xep-0156.html'>http://www.xmpp.org/extensions/xep-0156.html</link>>.</note>" >
|
||||
<!ENTITY xep0157 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0157.html'>Contact Addresses for XMPP Services</link></span> <note>XEP-0157: Contact Addresses for XMPP Services <<link url='http://www.xmpp.org/extensions/xep-0157.html'>http://www.xmpp.org/extensions/xep-0157.html</link>>.</note>" >
|
||||
<!ENTITY xep0158 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0158.html'>Robot Challenges</link></span> <note>XEP-0158: Robot Challenges <<link url='http://www.xmpp.org/extensions/xep-0158.html'>http://www.xmpp.org/extensions/xep-0158.html</link>>.</note>" >
|
||||
<!ENTITY xep0158 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0158.html'>CAPTCHA Forms</link></span> <note>XEP-0158: CAPTCHA Forms <<link url='http://www.xmpp.org/extensions/xep-0158.html'>http://www.xmpp.org/extensions/xep-0158.html</link>>.</note>" >
|
||||
<!ENTITY xep0159 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0159.html'>SPIM-Blocking Control</link></span> <note>XEP-0159: SPIM-Blocking Control <<link url='http://www.xmpp.org/extensions/xep-0159.html'>http://www.xmpp.org/extensions/xep-0159.html</link>>.</note>" >
|
||||
<!ENTITY xep0160 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0160.html'>Best Practices for Handling Offline Messages</link></span> <note>XEP-0160: Best Practices for Handling Offline Messages <<link url='http://www.xmpp.org/extensions/xep-0160.html'>http://www.xmpp.org/extensions/xep-0160.html</link>>.</note>" >
|
||||
<!ENTITY xep0161 "<span class='ref'><link url='http://www.xmpp.org/extensions/xep-0161.html'>SPIM Reporting</link></span> <note>XEP-0161: SPIM Reporting <<link url='http://www.xmpp.org/extensions/xep-0161.html'>http://www.xmpp.org/extensions/xep-0161.html</link>>.</note>" >
|
||||
|
Loading…
Reference in New Issue
Block a user