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.

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 (e.g., 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.

An entity (client or server) MAY send a challenge immediately after receiving a stanza from another entitiy. An entity MUST NOT send challenges under any other circumstances. Hereafter, the entity that generates the stanza that triggers the challenge is called the "sender" and the entity that sends the challenge is called the "challenger".

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.

If the sender 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 sender MUST also answer one or more of the challenges without a <required/> element. In the example above, the sender should respond to the 'qa' challenge and one of the other challenges ('ocr', 'audio_recog' or 'SHA-256').

The challenger MAY decide the sender has passed a challenge even if the responses are not all perfectly correct.

Entities MUST address the needs of disabled people and CPU-constrained clients by offering people 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. A CPU-constrained client could ask a faster computer (e.g., its server) to perform a Hashcash challenge for it.

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.

Challenge types are distinguished by the 'var' attribute of each <field/> element. Several types of challenges are described below. More challenges MAY be documented elsewhere and registered with the XMPP Registrar (see Field Standardization).

The SHA-256 Hashcash challenge is transparent to average PC users. It is indicated when the value of the 'var' attribute is 'SHA-256'. It forces clients to perform CPU-intensive work, making it difficult to send large amounts of spim. This significantly reduces spim, but alone it will not completely stop spim being sent through large collections of 'zombie' computers. The hope is that the extra CPU usage will often be noticed by the owners of the zombie machines, who will be more likely to fix them.

The challenger MUST set the 'label' attribute of the <field/> element to a hexadecimal random number containing a configured number of bits (e.g., 220 ≤ label < 221).

To pass the test, the sender MUST return a text string that starts with the JID the sender sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash (see &nistfips180-2;) of the string MUST equal the hexadecimal value specified by the challenger (in the 'label' attribute of the <field/> element). For example, if the 'label' attribute is the 20-bit value 'e03d7' then the following string would be correct:

Note: When configuring the number of bits to be specified by a challenger in the 'label' attribute values, administrators MUST balance the need to make mass spim as difficult as possible, with the inconvenience that may be caused to the users of less powerful computers. (Most clients will be challenged only very occasionally, so the consumption of 70% of a typical desktop CPU for 4 seconds might be considered appropriate.) Administrators SHOULD increment the configured number of bits from time to time to match increases in the performance of typical desktop PCs. If an administrator notices that spim robots never attempt the Hashcash challenge, then he SHOULD consider reducing the number of bits, to avoid inconveniencing people unnecessarily.

For those CAPTCHA types where generic instructions are possible (see table below) then the <field/> element SHOULD NOT include a 'label' attribute (the client MUST present generic instructions to the sender in the language of its user interface). Otherwise the 'label' attribute SHOULD ask a specific question in the language indicated by the 'xml:lang' attribute of the challenge stanza.

If a media type is specified (see table below) then the <field/> element MUST contain a <media/> element that includes a <uri/> element of that type. Clients that support the CAPTCHA type MUST be able to play or render the specified MIME-types (see table below). They MAY also support other formats. Audio CAPTCHAs typically require challengers to provide at least the 'audio/x-wav' MIME-type (with the PCM codec) because more efficient patent-free formats are often not supported by constrained clients. It is RECOMMENDED that challengers provide more compact formats (like Ogg Speex or MP3) too.

The 'type' attribute of the <field/> element SHOULD be 'text-single', 'text-private', or 'text-multi' (if no 'type' is specified, the default is 'text-single'). The 'boolean' and 'list-single' field types would make it trivial for a robot to provide a correct response at least some of the time. The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.

* The image portrays random characters that humans can read but OCR software cannot. See PWNtcha <http://sam.zoy.org/pwntcha/> for some example OCR CAPTCHA images. To pass the challenge, the sender must simply type the characters. The correct answer SHOULD NOT depend on the language specified by the 'xml:lang' attribute of the challenge stanza.

** To pass the challenge, the sender must type the answer to the question in the 'label' attribute.

Note: It may be profitable to send spim even if less than one percent of CAPTCHA responses are successful. The effectiveness of a CAPTCHA challenge needs to be close to perfect, unless it is used in combination with other anti-spim techniques.

Until this specification advances to a status of Draft, its associated namespace shall be "http://www.xmpp.org/extensions/xep-00158.html#ns"; upon advancement of this specification, the ®ISTRAR; shall issue a permanent namespace in accordance with the process defined in Section 4 of &xep0053;.