From 9e1ae31e1957b5451c5f7178826fcf8f0f454d87 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 17 Jul 2008 02:53:22 +0000 Subject: [PATCH] renamed XEP-0158 per Council discussion git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@2091 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0158.xml | 4 ++-- xep-0159.xml | 8 ++++---- xep.ent | 2 +- 3 files changed, 7 insertions(+), 7 deletions(-) diff --git a/xep-0158.xml b/xep-0158.xml index 1eb78364..203cc781 100644 --- a/xep-0158.xml +++ b/xep-0158.xml @@ -6,7 +6,7 @@
- Robot Challenges + CAPTCHA Forms 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. &LEGALNOTICE; 0158 @@ -655,7 +655,7 @@

It is RECOMMENDED that entities employ other techniques to combat abusive stanzas in addition to those described in this document (e.g., see XEP-0161 and &xep0205;).

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.

-

The administrator of an application that functions as a challenger SHOULD discontinue the use of Robot Challenges under the following circumstances:

+

The administrator of an application that functions as a challenger SHOULD discontinue the use of CAPTCHA forms under the following circumstances:

  • 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.
  • If other, more transparent, techniques being employed by the challenger are so successful that challenges are offering only negligible additional protection against abusive traffic.
    • diff --git a/xep-0159.xml b/xep-0159.xml index dff56a77..8efc9eaf 100644 --- a/xep-0159.xml +++ b/xep-0159.xml @@ -87,7 +87,7 @@

    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 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.).

    -

    For example, a server could employ traffic and reputation analysis to filter the majority of spim, and use Robot Challenges to identify the remainder (feeding what it learns back to the traffic and reputation analysis).

    +

    For example, a server could employ traffic and reputation analysis to filter the majority of spim, and use CAPTCHA Forms to identify the remainder (feeding what it learns back to the traffic and reputation analysis).

     @@ -137,7 +137,7 @@
  • The server MAY allow or deny delivery of the stanza at any time (for reasons not defined in this document).

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.

-

A good example of a delayed spim recognition procedure is when servers use the Robot Challenges protocol to confirm whether or not a client is a spim robot before denying or allowing the delivery of a stanza from a new correspondent. 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. If a human user fails such a robot challenge then his client SHOULD give him the option to resend the stanza immediately.

+

A good example of a delayed spim recognition procedure is when servers use the CAPTCHA Forms protocol to confirm whether or not a client is a spim robot before denying or allowing the delivery of a stanza from a new correspondent. 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. If a human user fails such a robot challenge then his client SHOULD give him the option to resend the stanza immediately.

 @@ -148,7 +148,7 @@

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).

-

At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive spim recognition techniques (like Robot Challenges). 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).

+

At least in the medium term, clients that use non-XMPP protocols cannot be expected to support interactive spim recognition techniques (like CAPTCHA Forms). 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).

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).

@@ -188,7 +188,7 @@ -

No spim recognition techniques are perfect. Senders are sometimes falsely identified as spim bots. (For example, when a server sends Robot Challenges, but the client does not support that protocol.)

+

No spim recognition techniques are perfect. Senders are sometimes falsely identified as spim bots. (For example, when a server sends CAPTCHA Forms, but the client does not support that protocol.)

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:

  • simply send him a message, so her server adds him to her correspondents list
    • diff --git a/xep.ent b/xep.ent index 41617265..d60bc2bd 100644 --- a/xep.ent +++ b/xep.ent @@ -911,7 +911,7 @@ IANA Service Location Protocol, Version 2 (SLPv2) Templates Stanza Session Negotiation XEP-0155: Stanza Session Negotiation <http://www.xmpp.org/extensions/xep-0155.html>." > Discovering Alternative XMPP Connection Methods XEP-0156: Discovering Alternative XMPP Connection Methods <http://www.xmpp.org/extensions/xep-0156.html>." > Contact Addresses for XMPP Services XEP-0157: Contact Addresses for XMPP Services <http://www.xmpp.org/extensions/xep-0157.html>." > -Robot Challenges XEP-0158: Robot Challenges <http://www.xmpp.org/extensions/xep-0158.html>." > +CAPTCHA Forms XEP-0158: CAPTCHA Forms <http://www.xmpp.org/extensions/xep-0158.html>." > SPIM-Blocking Control XEP-0159: SPIM-Blocking Control <http://www.xmpp.org/extensions/xep-0159.html>." > Best Practices for Handling Offline Messages XEP-0160: Best Practices for Handling Offline Messages <http://www.xmpp.org/extensions/xep-0160.html>." > SPIM Reporting XEP-0161: SPIM Reporting <http://www.xmpp.org/extensions/xep-0161.html>." >