This JEP specifies a protocol entities may use to discover whether an XMPP client is a human user or a robot.
WARNING: This Standards-Track JEP is Experimental. Publication as a Jabber Enhancement Proposal does not imply approval of this proposal by the Jabber Software Foundation. Implementation of the protocol described herein is encouraged in exploratory implementations, but production systems should not deploy implementations of this protocol until it advances to a status of Draft.
Status: Experimental
Type: Standards Track
Number: 0158
Version: 0.1
Last Updated: 2005-09-14
JIG: Standards JIG
Approving Body: Jabber Council
Dependencies: XMPP Core, XMPP IM, JEP-0004, JEP-0066
Supersedes: None
Superseded By: None
Short Name: challenge
Email: ian.paterson@clientside.co.uk
JID: ian@zoofy.com
This Jabber Enhancement Proposal is copyright 1999 - 2005 by the Jabber Software Foundation (JSF) and is in full conformance with the JSF's Intellectual Property Rights Policy <http://www.jabber.org/jsf/ipr-policy.shtml>. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at <http://www.opencontent.org/openpub/>).
The preferred venue for discussion of this document is the Standards-JIG discussion list: <http://mail.jabber.org/mailman/listinfo/standards-jig>.
The Extensible Messaging and Presence Protocol (XMPP) is defined in the XMPP Core (RFC 3920) and XMPP IM (RFC 3921) specifications contributed by the Jabber Software Foundation to the Internet Standards Process, which is managed by the Internet Engineering Task Force in accordance with RFC 2026. Any protocol defined in this JEP has been developed outside the Internet Standards Process and is to be understood as an extension to XMPP rather than as an evolution, development, or modification of XMPP itself.
The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
The appearance of large public IM services based on RFC 3920 [1] and RFC 3921 [2] created an urgent need to implement protocols that discourage 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).
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" (CAPTCHA). 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.
An alternative technique to CAPTCHAs requires Desktop PC clients to undertake a Hashcash [3] 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.
The generic challenge protocol described in this document is designed for incorporation into other protocols like In-Band Registration [4] and SPIM-Blocking Control [5].
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 Inaccessibility of Visually-Oriented Anti-Robot Tests [6]). 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.
This protocol requires multimedia to be included within Data Forms [7]. 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.
The <media/> element MUST contain a 'type' atribute that specifies the MIME type (see RFC 2045 [8]) of the media. If the media is an image or video, 'width' and 'height' attributes SHOULD also be included, specifying the recommended display size of the media in pixels.
The <media/> element SHOULD contain a <uri/> element to specify the out-of-band location of the media data. [9] The <uri/> element MUST contain a URI that indicates the location.
The <media/> element MAY also contain a <data/> element for distributing the media in-band. The <data/> element MUST contain the Base64 encoded (in accordance with Section 3 of RFC 3548 [10]) media data. The encoded 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.
Example 1. JPEG Photo
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='image/jpeg'
width='100'
height='120'>
<uri>http://www.mydomain.com/photo.jpeg</uri>
<data> ** Base64 encoded image ** </data>
</media>
An entity (client or server) MAY send a challenge to a client immediately after receiving a stanza from the client. Entities MUST NOT send challenges under any other circumstances.
Example 2. Client Sends Stanza Via Server
<message from='robot@spimmer.com/zombie'
to='victim@mydomain.com'
xml:lang='en'
id='spam1'>
<body>Love pills - 75% OFF</body>
<x xmlns='jabber:x:oob'>
<url>http://www.spimmer.com/lovepills.html</url>
</x>
</message>
Each of the challenge form's <field/> elements (see Data Forms) 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 Field Standardization for Data Forms [11].
The entity SHOULD include an explanation (in the <body/> element) for clients that do not support this protocol. The entity MAY also include a URL (typically a Web page with instructions) using Out-of-Band Data [12] as an alternative for clients that do not support the challenge form. Note: even if it provides a URL then an entity MUST provide a challenge form. [13]
Example 3. Server Offers a Choice of Challenges to a Client
<message from='mydomain.com'
to='robot@spimmer.com/zombie'
xml:lang='en'
id='F3A6292C'>
<body>Your messages to victim@mydomain.com are being blocked.
Visit the Web page to unblock them.</body>
<x xmlns='jabber:x:oob'>
<url>http://www.mydomain.com/challenge.html?F3A6292C</url>
</x>
<challenge xmlns='http://jabber.org/protocol/challenge'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/challenge</value>
</field>
<field type='hidden' var='from'><value>victim@mydomain.com</value></field>
<field type='hidden' var='sid'><value>spam1</value></field>
<field type='text-single' var='ocr'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='image/jpeg'
width='290'
height='80'>
<uri>http://www.mydomain.com/challenges/ocr.jpeg?F3A6292C</uri>
<data> ** Base64 encoded image ** </data>
</media>
</field>
<field type='text-single' var='picture'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='image/jpeg'
width='150'
height='150'>
<uri>http://www.mydomain.com/challenges/picture.jpeg?F3A6292C</uri>
<data> ** Base64 encoded image ** </data>
</media>
</field>
<field type='text-single' var='speech'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='audio/mpeg'>
<uri>http://www.mydomain.com/challenges/speech.mp3?F3A6292C</uri>
<data> ** Base64 encoded audio ** </data>
</media>
</field>
<field type='text-single' var='video'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='video/mpeg'>
<uri>http://www.mydomain.com/challenges/video.mpeg?F3A6292C</uri>
<data> ** Base64 encoded video ** </data>
</media>
</field>
<field label='Type the color of a stop light'
type='text-single'
var='qa'/>
<field label='93C7A' type='text-single' var='sha256'/>
</x>
</challenge>
</message>
The client SHOULD ignore the challenge stanza in either of the following cases:
Otherwise, if the entity provided a URL using Out-of-Band Data, then the client MAY present the URL to its user, instead of responding to the challenge form, in any of the following cases:
Otherwise, the client MUST respond to the entity, preserving the 'id' attribute of the challenge stanza.
The client MUST respond with a <not-acceptable/> error in any of the following cases:
Example 4. Client Reports an Error
<message type='error'
from='robot@spimmer.com/zombie'
to='mydomain.com'
xml:lang='en'
id='F3A6292C'>
<error type='cancel'>
<not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</message>
Otherwise, it MUST select one challenge according to the user's preferences and submit the user's response form to the entity.
Example 5. Client Sends one Response to the Server
<iq type='set'
from='robot@spimmer.com/zombie'
to='mydomain.com'
xml:lang='en'
id='F3A6292C'>
<challenge xmlns='http://jabber.org/protocol/challenge'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/challenge</value>
</field>
<field var='from'><value>victim@mydomain.com</value></field>
<field var='sid'><value>spam1</value></field>
<field var='ocr'><value>7nHL3</value></field>
</x>
</challenge>
</iq>
After receiving a correct response to its challenge, the entity SHOULD inform the client that it was successful.
Example 6. Server Tells the Client it Passed
<iq type='result'
from='mydomain.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'/>
However, the entity SHOULD send a <service-unavailable/> error to the client if:
Note: This error MAY be sent even in cases where the challenge became unnecessary while the server was waiting for the response.
Example 7. Server Indicates an Error
<iq type='error'
from='mydomain.com'
to='robot@spimmer.com/zombie'
id='F3A6292C'>
<error type='cancel'>
<service-unavailable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
</error>
</iq>
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.
Example 8. Server Sets Multiple Challenges
<message from='mydomain.com'
to='robot@spimmer.com/zombie'
xml:lang='en'
id='73DE28A2'>
<body>Your messages to victim@mydomain.com are being blocked.
To unblock them, ask victim@mydomain.com to send you a message.</body>
<challenge xmlns='http://jabber.org/protocol/challenge'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/challenge</value>
</field>
<field type='hidden' var='from'><value>victim@mydomain.com</value></field>
<field type='hidden' var='sid'><value>spam2</value></field>
<field type='hidden' var='answers'><value>2</value></field>
<field type='text-single' var='ocr'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='image/jpeg'
width='290'
height='80'>
<uri>http://www.mydomain.com/challenges/ocr.jpeg?F3A6292C</uri>
</media>
</field>
<field type='text-single' var='audio'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='audio/mpeg'>
<uri>http://www.mydomain.com/challenges/audio.mp3?F3A6292C</uri>
</media>
</field>
<field label='Type the color of a stop light'
type='text-single'
var='qa'>
<required/>
</field>
<field label='e03d7' type='text-single' var='sha256'/>
</x>
</challenge>
</message>
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 and one of the other challenges ('ocr', 'audio' or 'sha256').
Example 9. Client Sends Multiple Responses to the Server
<iq type='set'
from='robot@spimmer.com/zombie'
to='mydomain.com'
xml:lang='en'
id='73DE28A2'>
<challenge xmlns='http://jabber.org/protocol/challenge'>
<x xmlns='jabber:x:data' type='submit'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/challenge</value>
</field>
<field var='from'><value>victim@mydomain.com</value></field>
<field var='sid'><value>spam2</value></field>
<field var='answers'><value>2</value></field>
<field var='qa'><value>divad</value></field>
<field var='sha256'><value>victim@mydomain.com2450F06C173B05E3</value></field>
</x>
</challenge>
</iq>
The entity MAY decide the client has passed a challenge even if the responses are not all perfectly correct.
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.
Example 10. Entity Requests Registration Fields from Host
<iq type='get' xml:lang='en' id='reg1'>
<query xmlns='jabber:iq:register'/>
</iq>
Note that the challenge form MUST be inside the <query/> element, and the server's challenge ID is specified within the form:
Example 11. Host Returns Registration and Challenge Fields to Entity
<iq type='result' xml:lang='en' id='reg1'>
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='form'>
<field type='hidden' var='FORM_TYPE'>
<value>http://jabber.org/protocol/challenge</value>
</field>
<field type='hidden' var='cid'><value>F3A6292C</value></field>
<field type='hidden' var='answers'><value>3</value></field>
<field type='text-single' var='ocr'>
<media xmlns='xmlns='http://jabber.org/protocol/media'
type='image/jpeg'
width='290'
height='80'>
<uri>http://www.mydomain.com/challenges/ocr.jpeg?F3A6292C</uri>
</media>
</field>
<field label='93C7A' type='text-single' var='sha256'/>
<field type='text-single' var='username'>
<required/>
</field>
<field type='text-single' var='password'>
<required/>
</field>
</x>
<instructions>
To register, visit http://www.mydomain.com/register.html
</instructions>
<x xmlns='jabber:x:oob'>
<url>http://www.mydomain.com/register.html</url>
</x>
</query>
</iq>
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 entity SHOULD submit the completed x:data form, however if it does not understand the form, then it MAY present the instructions and the provided URL to the user instead of providing the required information in-band.
Example 12. Entity Provides Required Information In-Band
<iq type='set' xml:lang='en' id='reg2'>
<query xmlns='jabber:iq:register'>
<x xmlns='jabber:x:data' type='result'>
<field var='FORM_TYPE'>
<value>http://jabber.org/protocol/challenge</value>
</field>
<field var='cid'><value>F3A6292C</value></field>
<field var='answers'><value>3</value></field>
<field var='ocr'><value>7nHL3</value></field>
<field var='username'><value>bill</value></field>
<field var='password'><value>Calliope</value></field>
</x>
</query>
</iq>
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 'sha256' 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. [16]
Visually disabled people using a CPU-constrained client could configure their client to always present them with an 'audio' or 'speech' 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 client 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 Jabber Registrar [17] (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 'sha256'. 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. [18]
The entity MUST set the 'label' attribute of the <field/> element to a hexadecimal random number containing a configured number of bits (220 ≤ label < 221, for example).
To pass the test, the client MUST return a text string that starts with the JID the client sent the first stanza to (i.e., the stanza that triggered the challenge). The least significant bits of the SHA-256 hash of the string MUST equal the hexadecimal value specified by the entity (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:
victim@mydomain.com2450F06C173B05E3
Note: When configuring the number of bits to be specified by an entity 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 its user 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 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.
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'). [19] The response MUST be provided in the language specified by the 'xml:lang' attribute of the challenge stanza.
Table 1: CAPTCHAs
| 'var' | Name | Media type | MIME-type | 'label' | Example generic instructions |
|---|---|---|---|---|---|
| *ocr | Optical Character Recognition | image | image/jpeg | No | Enter the code you see |
| picture | Picture Recognition | image | image/jpeg | No | Describe the picture |
| video | Video Recognition | video | video/jpeg | No | Describe the video |
| audio | Audio Recognition | audio | audio/mp3 | No | Describe the sound you hear |
| speech | Speech Recognition | audio | audio/mp3 | No | Enter the words you hear |
| qa | Question and Answer | - | - | **Yes | - |
* The image portrays random characters that humans can read but OCR software cannot. [20] To pass the challenge, the user 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 user 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.
It is RECOMMENDED that entities employ other techniques to combat SPIM in addition to those described in this document. The expectation is that this protocol will be an important and successful tool for discouraging SPIM. However, much of its success is dependent on the quality of the CAPTCHAs employed by a particular implementation.
The administrator of an entity MUST discontinue the use of Robot Challenges under the following circumstances:
This JEP introduces no security considerations above and beyond those described in RFC 3920 and RFC 3921.
This JEP requires no interaction with the Internet Assigned Numbers Authority (IANA) [21].
Upon approval of this JEP, the Jabber Registrar shall register the following protocol namespaces:
Upon approval of this JEP, the Jabber Registrar shall register the following new FORM_TYPE. Additional fields will be defined in future submissions.
<form_type>
<name>http://jabber.org/protocol/challenge</name>
<doc>JEP-0158</doc>
<desc>forms enabling robot challenges</desc>
<field
var='from'
type='hidden'
label='to attribute of stanza that triggered challenge '/>
<field
var='sid'
type='hidden'
label='stanza ID'/>
<field
var='cid'
type='hidden'
label='challenge ID'/>
<field
var='answers'
type='hidden'
label='number of answers required'/>
<field
var='ocr'
type='text-single'
label='code appearing in an image'/>
<field
var='picture'
type='text-single'
label='text associated with a picture'/>
<field
var='video'
type='text-single'
label='text associated with a video'/>
<field
var='audio'
type='text-single'
label='text associated with a sound'/>
<field
var='speech'
type='text-single'
label='text associated with speech'/>
<field
var='qa'
type='text-single'
label='answer to a question'/>
<field
var='sha256'
type='text-single'
label='least significant bits of SHA-256 hash of text should equal hexadecimal label'/>
</form_type>
Upon approval of this JEP, the Jabber Registrar shall register the following new fields for the existing jabber:iq:register FORM_TYPE. Additional fields will be defined in future submissions.
<form_type>
<name>jabber:iq:register</name>
<doc>JEP-0077</doc>
<field
var='cid'
type='hidden'
label='challenge ID'/>
<field
var='answers'
type='hidden'
label='number of answers required'/>
<field
var='ocr'
type='text-single'
label='code appearing in an image'/>
<field
var='picture'
type='text-single'
label='text associated with a picture'/>
<field
var='video'
type='text-single'
label='text associated with a video'/>
<field
var='audio'
type='text-single'
label='text associated with a sound'/>
<field
var='speech'
type='text-single'
label='text associated with speech'/>
<field
var='qa'
type='text-single'
label='answer to a question'/>
<field
var='sha256'
type='text-single'
label='least significant bits of SHA-256 hash of text should equal hexadecimal label'/>
</form_type>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/challenge'
xmlns='http://jabber.org/protocol/challenge'
elementFormDefault='qualified'>
<xs:element name='challenge'>
<xs:complexType>
<xs:sequence xmlns:xdata='jabber:x:data'>
<xs:element ref='xdata:x' minOccurs='1' maxOccurs='1'/>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>
<?xml version='1.0' encoding='UTF-8'?>
<xs:schema
xmlns:xs='http://www.w3.org/2001/XMLSchema'
targetNamespace='http://jabber.org/protocol/media'
xmlns='http://jabber.org/protocol/media'
elementFormDefault='qualified'>
<xs:element name='media'>
<xs:complexType>
<xs:sequence>
<xs:element ref='uri' minOccurs='1' maxOccurs='1'/>
<xs:element ref='data' minOccurs='0' maxOccurs='1'/>
</xs:sequence>
<xs:attribute name='height' type='xs:string' use='optional'/>
<xs:attribute name='type' type='xs:string' use='required'/>
<xs:attribute name='width' type='xs:string' use='optional'/>
</xs:complexType>
</xs:element>
<xs:element name='uri' type='xs:string'/>
<xs:element name='data' type='xs:string'/>
</xs:schema>
Another protocol could allow users to edit the challenges their server will make on their behalf. For example, the number of sha256 bits, a personal or original question and answer, a picture, a video, or a sound recording... Of course Aunt Tillie would typically only use this feature if she was plagued by SPIM.
1. RFC 3920: Extensible Messaging and Presence Protocol (XMPP): Core <http://www.ietf.org/rfc/rfc3920.txt>.
2. RFC 3921: Extensible Messaging and Presence Protocol (XMPP): Instant Messaging and Presence <http://www.ietf.org/rfc/rfc3921.txt>.
3. Hashcash <http://hashcash.org/>.
4. JEP-0077: In-Band Registration <http://www.jabber.org/jeps/jep-0077.html>.
5. JEP-0159: SPIM-Blocking Control <http://www.jabber.org/jeps/jep-0159.html >.
6. Inaccessibility of Visually-Oriented Anti-Robot Tests <http://www.w3.org/TR/turingtest/>.
7. JEP-0004: Data Forms <http://www.jabber.org/jeps/jep-0004.html>.
8. RFC 2045: Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies <http://www.ietf.org/rfc/rfc2045.txt>.
9. Constrained execution environments prevent some clients rendering media unless it has been received out-of-band (e.g., Web clients).
10. RFC 3548: The Base16, Base32, and Base64 Data Encodings <http://www.ietf.org/rfc/rfc3548.txt>.
11. JEP-0068: Field Data Standardization for Data Forms <http://www.jabber.org/jeps/jep-0068.html>.
12. JEP-0066: Out of Band Data <http://www.jabber.org/jeps/jep-0066.html>.
13. A constrained client, like a mobile phone, cannot present a Web page to its user.
14. Otherwise the user's presence would be disclosed, or a SPIM robot might dupe the user into providing answers to other people's challenges!
15. 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.
16. A CPU-constrained client could ask a faster computer (its server, for example) to perform a Hashcash challenge for it.
17. The Jabber Registrar maintains a list of reserved Jabber protocol namespaces as well as registries of parameters used in the context of protocols approved by the Jabber Software Foundation. For further information, see <http://www.jabber.org/registrar/>.
18. 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.
19. 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.
20. See PWNtcha <http://sam.zoy.org/pwntcha/> for some example OCR CAPTCHA images.
21. The Internet Assigned Numbers Authority (IANA) is the central coordinator for the assignment of unique parameter values for Internet protocols, such as port numbers and URI schemes. For further information, see <http://www.iana.org/>.
END