An implementation of Instant Gaming MUST support &xep0030;.

A Jabber entity may wish to discover if another entity implements the Instant Gaming protocol; in order to do so, it sends a service discovery information ("disco#info") query to the other entity's full JID:

The entity MUST return the features it supports. Game protocols SHOULD include a &FEATURE; element with their namespace in the response, too.

In order to invite someone to a game, the initiator sends a message to her/his opponent containing an &INVITE; element, which MUST specify the invitation type (see Table 1).

Furthermore, a &GAME; element with a "var" attribute containing the namespace of the game protocol is REQUIRED. It MAY also contain additional information which SHOULD then be specified using &xep0004;. Such information might be used to state the rules or other slight variations for the particular game. If an invitation with unsupported rules or options is received, a ¬acceptable; error of type "modify" SHOULD be send to the inviting entity.

The &THREAD; element MUST be present and it MUST contain a unique ID which identifies the current match. The ID MAY for example consist of the initiator's and the opponent's (bare) JID, the game name, the current datetime (which then SHOULD conform to the DateTime profile specified in &xep0082;) and a random number, all separated by hyphens. It is not supposed to get parsed and is only used to uniquely identify the game.

An invitation of type "renew" SHOULD contain the same match ID and &GAME; element as the initial "new" invitation. It MUST only be send when the previous match with the same match ID has been terminated. If it is received earlier, an &unexpected; error SOULD be send to the sender of the premature invitation. Game protocols SHOULD switch the beginning player and leave all other options the same.

In the unlikely but possible event that an invitation of type "renew" is received immediately after one has been send with the same match ID, this invitation SHOULD be treated as if it were a &MESSAGE; with a &JOIN; element. Invitations with match IDs that are already assigned to a running game SHOULD be ignored.

The opponent SHOULD NOT ignore the invitation. If she/he does not want to play, the invitation SHOULD be declined. In order to decline the invitation, the opponent MUST send a message of the following form to the initiator.

In order to join a game, a &MESSAGE; stanza has to be send to the initiator's full JID. The &MESSAGE; stanza MUST contain the ID of the match to which the opponent wants to join in the &THREAD; element. Besides that, a &JOIN; element qualified by the namespace 'http://jabber.org/protocol/games' is REQUIRED and the &BODY; element is OPTIONAL.

A successful join MUST be confirmed by sending the same message (with different sender and recipient) back to the opponent.

The initiator might refuse the join by sending a &MESSAGE; stanza of 'type' "error". It then MUST mirror the &THREAD; ID and the original &JOIN; child element. The &ERROR; element MAY contain a &TEXT; element with a human-readable description of the error.

A turn in a game is sent in a message (of type "chat") to the other player's full JID. The &MESSAGE; stanza contains a &TURN; element which contains the element, representing the desired action (e.g. &MOVE;) qualified by the namespace of the particular game. The action itself can be further described by attributes or child elements (see corresponding game protocol).

A human-readable comment MAY be sent with the move in the &BODY; element of the &MESSAGE;. In order to track the game to which the move belongs, the match ID is REQUIRED to be in the &THREAD; element.

A receipt for each message MAY be requested in accordance with &xep0184;.

While playing a game, it might be desirable to interrupt playing and resume it at a later time. Games with complete knowledge can be saved at any time by each of the players without sending messages. But the client of the saving player SHOULD inform the other player that the game was saved by sending the following message.

After receiving such an notification, an implementation MAY decide to save the game, too.

When playing games with incomplete knowledge, it is desirable that both players save the game at the same time in order to save a clean game state. The game protocol MUST define whether its game has to be saved independently or mutually.

If a game needs to be saved mutually by both players, one of the players requests the game to be saved by sending a message with a &SAVE; child element as follows.

The recipient of the above message MUST confirm a successful saving process using a &SAVED; element as above.

To ensure that both players save the same game state, the sender MUST NOT send any game moves until he receives confirmation from the other player and the receiver MUST NOT send any game moves after receiving the request for saving until he has responded to it.

If the sender of the saving request receives a game move before getting confirmation of a successful saving process, she/he MUST NOT save the game and MUST send the following error message.

If one of the player's client encounters an error during the saving process, it MUST send an error message, too. This time it SHOULD NOT use a &conflict;, but an &undefined; error condition.

An XMPP entity that wishes to resume a saved game has to send an invitation of "type" 'adjourned' to the same opponent it began playing with. It MAY also resume the game with another opponent, but then it MUST use the "type" 'constructed' and a new match ID.

In case the game requires mutual saving by both players and the game was saved this way, one of the players simply sends an invitation of "type" 'adjourned' with the match ID of the saved game to the other player. After the invitee has successfully joined the game, it begins at the point where it was saved.

If the game was only saved by one of the players, the inviting player MUST send the saved game state in the invitation. This SHOULD be done by including an &X; element in the &MESSAGE; stanza of the 'jabber:x:data' namespace. The exact representation of the game state is up to the game protocol, but SHOULD use &xep0004;. E.g. the state MAY also be encoded in a history of game moves.

The Tic Tac Toe game state information in this example is entirely fictional and only for demonstration purposes.

An implementation MAY present the game in the saved state to the user along with the invitation. It MAY also compare the state it received with the state it saved by its own and inform the user about any mismatches.

An implementation SHOULD send the following &MESSAGE; to end the game. The "reason" attribute is always REQUIRED.

This &MESSAGE; SHOULD also be send by one of the players before she/he changes her/his presence to unavailable, though a different "reason" MAY be used. For a list of possible reasons and their meaning see Table 2.

In case one player changes her/his presence to unavailable without sending a termination message, the other player might just wait or MAY save the game (if possible) and send a termination message with reason 'adjourn'.

A terminating &MESSAGE; with reason 'cheating' SHOULD be send, if an illegal move is received. If one entity receives a terminating &MESSAGE; although it already send one by it's own, it MUST ignore it.