Generalized text to cover abuse rather than just spim; modified temporary namespace to adhere to XMPP Registrar procedures; added use case for joining multi-user chat rooms.
The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that discourage the sending of large quantities of instant messaging spam (a.k.a. "spim"). Spim could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Spim is defined here as any type of unsolicited XMPP stanza sent by a "robot" and delivered to a human, including messages and subscription requests. Spim has the potential to disrupt people even more than spam, because each message interrupts the receiver (humans typically filter SPAM in batch mode).
-Several of the most effective techniques developed to combat SPAM require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage spim. The very occasional inconvenience of responding to a CAPTCHA (e.g., when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.
+The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that discourage the sending of large quantities of instant messaging spam (a.k.a. "spim") or, in general, abusive traffic. Abusive stanzas could be generated by XMPP clients connected to legitimate servers or by XMPP servers with virtual clients, where the malicious entities are hosted on networks of "zombie" machines. Such abusive stanas could take many forms; a full taxonomy is outside the scope of this document.
+Several of the most effective techniques developed to combat abusive messages and behavior via non-XMPP technologies require humans to be differentiated from bots using a "Completely Automated Public Turing Test to Tell Computers and Humans Apart" or CAPTCHA (see <http://www.captcha.net/>). These challenge techniques are easily adapted to discourage XMPP abuse. The very occasional inconvenience of responding to a CAPTCHA (e.g., when creating an IM account or sending a message to a new correspondent) is small and perfectly acceptable -- especially when compared to the countless robot-generated interruptions people might otherwise have to filter every day.
An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash
The generic challenge protocol described in this document is designed for incorporation into protocols such as &xep0077; and &xep0159;.
+The generic challenge protocol described in this document is designed for incorporation into protocols such as &xep0077;, &xep0045;, and &xep0159;.
The challange consists of a message containing a form for the sender to fill out, formatted according to &xep0004;. Each of the challenge form's <field/> elements that are not hidden MAY contain a different challenge and any media required for the challenge (see &xep0221;). The hidden 'from' field MUST contain the value of the 'to' attribute of the sender's triggering stanza. If the stanza from the sender included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the sender. In accordance with &xep0068;, the hidden 'FORM_TYPE' field MUST have a value of "http://www.xmpp.org/extensions/xep-0158.html#ns" &NSNOTE;.
+The challange consists of a message containing a form for the sender to fill out, formatted according to &xep0004;. Each of the challenge form's <field/> elements that are not hidden MAY contain a different challenge and any media required for the challenge (see &xep0221;). The hidden 'from' field MUST contain the value of the 'to' attribute of the sender's triggering stanza. If the stanza from the sender included an 'id' attribute then the hidden 'sid' field MUST be set to that value. The 'xml:lang' attribute of the challenge stanza SHOULD be the same as the one received from the sender. In accordance with &xep0068;, the hidden 'FORM_TYPE' field MUST have a value of "urn:xmpp:tmp:challenge" &NSNOTE;.
The challenger SHOULD include an explanation (in the &BODY; element) for clients that do not support this protocol. The challenger MAY also include a URL (typically a Web page with instructions) using &xep0066; as an alternative for clients that do not support the challenge form. Note: Even if it provides a URL, a challenger MUST always provide a challenge form.
However, if the sender submits an incorrect response the challenger SHOULD send it a ¬acceptable; error with type "cancel":
However, if the sender submits an incorrect response the challenger SHOULD send it a ¬acceptable; error with type "cancel":
The challenger may demand responses to more than one of the challenges it is offering by including an 'answers' <field/> element in the form. It may require responses to particular challenges by including <required/> elements in the compulsory fields.
+The challenger MAY demand responses to more than one of the challenges it is offering; this is done by including an 'answers' <field/> element in the form. The challenger also MAY require responses to particular challenges; this is done by including <required/> elements in the compulsory fields.
This section shows how challenges SHOULD be combined with the existing registration protocol according to the rules defined in the Extensibility section of In-Band Registration. Note: The <challenge/> wrapper element is not required.
+This section shows how challenges SHOULD be combined with the existing In-Band Registration protocol according to the rules defined in the Extensibility section of XEP-0077.
+Note: The <challenge/> wrapper element is not included, because XEP-0077 specifies that data forms shall be contained as the direct children of the &QUERY; element.
Note that the challenge form MUST be inside the &QUERY; element, and the server's challenge ID is specified within the form:
The server MAY include an <instructions/> element and a URL using Out-of-Band Data (e.g., a web page) in the &QUERY; element (see example above). In-Band Registration recommends that the challenger SHOULD submit the completed x:data form, however if it does not understand the form, then it MAY present the instructions and the included URL to the user instead of providing the required information in-band.
-A service that hosts multi-user chat rooms in accordance with XEP-0045 MAY challenge unknown entities that seek to join such rooms or that send messages in such rooms.
+Entities MUST address the needs of disabled people and CPU-constrained clients by offering people a reasonable choice of different types of challenges.
+Entities MUST address the needs of disabled people and CPU-constrained clients by offering senders a reasonable choice of different types of challenges.
Desktop clients running on modern PCs will typically be configured to automatically perform a specified 'SHA-256' Hashcash challenge (see below) whenever it is below a certain level of difficulty, with the result that many people may not even notice challenges most of the time. However, people using CPU-constrained clients (e.g. Web or mobile clients) would notice the performance hit. They might prefer to take a CAPTCHA challenge instead.
Visually disabled people using a CPU-constrained client could configure their client to always present them with an audio CAPTCHA challenge.
Most of the challenges below are language sensitive. However, the evaluation of the OCR and Hashcash responses does not depend on the language the sender is using.
@@ -399,38 +497,6 @@* The image portrays random characters that humans can read but OCR software cannot.
An challenger MAY provide a text question in the &BODY; element of a challenge stanza for clients that do not support challenge forms. Entities that cannot serve Out-of-Band Data URLs MAY use this option to challenge legacy clients.
+A challenger MAY provide a text question in the &BODY; element of a challenge stanza for clients that do not support challenge forms. Entities that cannot serve Out-of-Band Data URLs MAY use this option to challenge legacy clients.
Note: Robots always attempt the easiest challenge they are offered. So the question MUST be at least as difficult for a robot as the challenge form.
Note: Even if it provides a text question in the &BODY; element, a challenger MUST always provide a challenge form.
@@ -490,10 +588,10 @@ id='F3A6292C'> Your messages to me are being blocked. To unblock them, reply with the color of a stop light followed by 'F3A6292C'. -Upon approval of this document, the XMPP Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.
- http://www.xmpp.org/extensions/xep-0158.html#ns
+ urn:xmpp:tmp:challenge
XEP-0158
forms enabling robot challenges