<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>
<p>The appearance of large public IM services based on &rfc3920; and &rfc3921; makes it desirable to implement protocols that <em>discourage</em> the sending of large quantities of IM SPAM (SPIM) from XMPP clients (connected to legitimate servers) and XMPP servers (with virtual clients) -- all 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).</p>
<p>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 <<linkurl='http://www.captcha.net/'>http://www.captcha.net/</link>>). These challenge techniques are easily adapted to discourage SPIM. The very occasional inconvenience of responding to a CAPTCHA (for example, 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.</p>
<p>An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a <spanclass='ref'>Hashcash</span><note>Hashcash <<linkurl='http://hashcash.org/'>http://hashcash.org/</link>>.</note> challenge. These are completely transparent to PC users. They require clients to perform specified CPU-intensive work, making it difficult to send large amounts of SPIM.</p>
<p>The CAPTCHAs in most common use today are Optical Character Recognition (OCR) challenges where an image containing deformed text is presented and the human enters the characters they can read. However if OCR software advances more rapidly than the techniques used to disguise text from Artificial Intelligence (AI) then very different CAPTCHAs will need to be deployed. This protocol must be extensible enough to allow the incorporation of CAPTCHA techniques that may not have been envisaged.</p>
</section2>
<section2topic='Variety'anchor='require-variety'>
<p>Several common CAPTCHA techniques present major problems to users with disabilities (see &w3turingtest;). Clients running in constrained environments may not be able to perform some challenges (for example, due to the absence of audio output or a lack of CPU performance). This protocol must allow clients to be offered a choice from a variety of challenges.</p>
<p>This protocol requires multimedia to be included within &xep0004;. This section defines a new namespace ('http://jabber.org/protocols/media') for that purpose. The root element for the namespace is <media/>. It MUST be contained within a <field/> element qualified by the 'jabber:x:data' namespace.</p>
<p>If the media is an image or video then the <media/> element SHOULD include 'width' and 'height' attributes specifying the recommended display size of the media in pixels.</p>
<p>The <media/> element SHOULD contain at least one <uri/> element to specify the out-of-band location of the media data. <note>Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients).</note> The <uri/> element MUST contain a URI that indicates the location.</p>
<p>The <media/> element MAY also contain one or more <data/> elements for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 3 of &rfc3548;) media data. The <em>encoded</em> data SHOULD NOT be larger than 8 KB. Note that if a stanza contains more than one <data/> element then the sending entity MUST take care not to trigger karma limits.</p>
<p>Each <uri/> or <data/> element MUST include a 'type' atribute that specifies the MIME type (see &rfc2045;) of the media.</p>
<p>An entity (client or server) MAY send a challenge to a client immediately after receiving a stanza from the client. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that sends a challenge is called a "challenger".</p>
<examplecaption='Client Sends Stanza Via Server'><![CDATA[
<p>Each of the challenge form's <field/> elements (see <cite>Data Forms</cite>) that are not hidden MAY contain a different challenge and any media required for the challenge. The hidden 'from' field MUST contain the value of the 'to' attribute of the client's stanza that triggered the challenge. If the stanza from the client 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 client. The hidden 'FORM_TYPE' field MUST have a value of "http://jabber.org/protocol/challenge" in accordance with &xep0068;.</p>
<p>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. <note>A constrained client, like a mobile phone, cannot present a Web page to its user.</note></p>
<p>The client SHOULD ignore the challenge stanza in either of the following cases:</p>
<ul>
<li>If it has not recently sent (in the last two minutes for example) a stanza to the JID specified in the 'from' field of the form with the 'id' specified in the 'sid' field (or with no 'id' if no 'sid' field is included). <note>Otherwise the user's presence would be disclosed, or a SPIM robot might dupe the user into providing answers to other people's challenges!</note></li>
<li>If the 'from' attribute of the challenge stanza does not match the 'from' field of the form. (If the values are different, then they still match if the bare JIDs are the same, or if the 'from' attribute is the domain of the other JID.)</li>
</ul>
<p>Otherwise, if the challenger provided a URL using <cite>Out-of-Band Data</cite>, then the client MAY present the URL to its user, instead of responding to the challenge form, in any of the following cases:</p>
<ul>
<li>if it does not understand the challenge form</li>
<li>if it does not support all of the <em>required</em> challenges (see <linkurl='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if it does not support enough of the challenges (see <linkurl='#protocol-multiple'>Multiple Challenges</link>)</li>
</ul>
<p>Otherwise, the client MUST respond to the challenger, preserving the 'id' attribute of the challenge stanza.</p>
<p>The client MUST respond with a ¬acceptable; error in any of the following cases:</p>
<ul>
<li>if it does not support all of the required challenges (see <linkurl='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if it does not support enough of the challenges (see <linkurl='#protocol-multiple'>Multiple Challenges</link>)</li>
<li>if its user declines the challenge</li>
</ul>
<examplecaption='Client Reports Challenge Not Acceptable'><![CDATA[
<p>The challenger SHOULD send a &unavailable; error to the client if:</p>
<ul>
<li>The challenger did not send the specified challenge. <note>If the challenger is a client then it SHOULD be careful not to leak information about the presence of its user and reply to potentially bogus challenge responses with exactly the same XML that its server would send if its user were offline.</note></li>
<li>The client already submitted its response to this challenge.</li>
<li>The client took too long to submit its response.</li>
</ul>
<p>Note: This error MAY be sent even in cases where the challenge became unnecessary while the challenger was waiting for the response.</p>
<examplecaption='Server Indicates Challenge Not Found'><![CDATA[
<p>After receiving a correct response to its challenge, the challenger SHOULD inform the client that it was successful.</p>
<examplecaption='Server Tells the Client it Passed'><![CDATA[
<iqtype='result'
from='victim.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'/>
]]></example>
<p>However, if the client submits an incorrect response the challenger SHOULD send it a ¬acceptable; error with type "cancel": <note>If a large proportion of the responses a server is receiving from another IP are incorrect then it SHOULD inform the administrator of the other server (using the protocol to be defined in a forthcoming proposal on SPIM reporting). It SHOULD also automatically block all stanzas from the abusive user, users, server or IP.</note></p>
<examplecaption='Server Tells the Client it Failed'><![CDATA[
<p>The enitity 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.</p>
<p>If the client finds the request acceptable, it MUST answer all challenges that include a <required/> element. If the total number of answers was specified and it is greater than the number of <required/> elements then the client MUST also answer one or more of the challenges without a <required/> element. In the example above, the client should respond to the 'qa' challenge <em>and</em> one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').</p>
<examplecaption='Client Sends Multiple Responses to the Server'><![CDATA[
<p>This section shows how challenges SHOULD be combined with the existing registration protocol according to the rules defined in the Extensibility section of <cite>In-Band Registration</cite>. Note: The <challenge/> wrapper element is not required.</p>
<examplecaption='Entity Requests Registration Fields from Host'><![CDATA[
<iqtype='get'xml:lang='en'id='reg1'>
<queryxmlns='jabber:iq:register'/>
</iq>
]]></example>
<p>Note that the challenge form MUST be inside the &QUERY; element, and the server's challenge ID is specified within the form:</p>
<examplecaption='Host Returns Registration and Challenge Fields to Entity'><![CDATA[
To register, visit http://www.victim.com/register.html
</instructions>
<xxmlns='jabber:x:oob'>
<url>http://www.victim.com/register.html</url>
</x>
</query>
</iq>
]]></example>
<p>The server MAY include an <instructions/> element and a URL using <cite>Out-of-Band Data</cite> (e.g., a web page) in the &QUERY; element (see example above). <cite>In-Band Registration</cite> 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.</p>
<examplecaption='Entity Provides Required Information In-Band'><