The main reason is that certain implementations might choose to base invitations on occupant JIDs rather than bare JIDs (so that, for example, an occupant could invite someone from one room to another without knowing that person's bare JID).
In order to decline the invitation, the invitee MUST send a message of the following form to the It may be wondered why the invitee does not send the decline message directly to the inviter.
The invitee MAY choose to formally decline (as opposed to ignore) the invitation; and this is something that the sender might want to be informed about.
Room Sends Invitation to Invitee on Behalf of Invitor If the room is members-only, the service MAY also add the invitee to the member list.
Because the room needs to be involved in the invitation process only for members-only rooms, because members-only rooms are relatively rare, and because mediated invitations do not work when element whose value is the bare JID, full JID, or occupant JID of the inviter and send the invitation to the invitee specified in the 'to' address; the room SHOULD add the password if the room is password-protected): Example 57.
The existence of two different invitation methods might cause confusion among client developers.
Mediated invitations were added in Multi-User Chat as a way to handle invitations in the context of members-only rooms (so that the room could exercise control over the issuance of invitations).
Direct invitations were the original method used in the early Jabber community's "groupchat 1.0" protocol.
Service Passes Along Changed Presence to All Occupants There are two ways of inviting another user to a room: direct invitations and mediated invitations.
In XMPP, availability is of course noted by a change in presence (specifically the If the room is configured to broadcast presence from entities with the occupant's role, the service then sends a presence stanza from the occupant changing his or her presence to the full JID of each occupant, including extended presence information about the occupant's role and full JID to those with privileges to view such information: Example 55.
This specification defines an XMPP protocol extension for multi-user text chat, whereby multiple XMPP users can exchange messages in the context of a room or channel, similar to Internet Relay Chat (IRC). Thus the service needs to handle both the invites and declines.
In addition to standard chatroom features such as room topics and invitations, the protocol defines a strong room control model, including the ability to kick and ban users, to name room moderators and administrators, to require membership or passwords in order to join the room, etc. element's 'thread' attribute, and include the Thread ID in any new messages sent to the room.
NOTICE: The protocol defined herein is a Draft Standard of the XMPP Standards Foundation. Use of Thread IDs is RECOMMENDED because it helps to provide continuity between the one-to-one chat and the multi-user chat. Continuing the Discussion I: User Creates Room protocol enables the room creator to specify the datetime of each message from the one-to-one chat history (via the 'stamp' attribute), as well as the JID of the original sender of each message (via the 'from' attribute); note well that the 'from' here is not the room itself, since the originator of the message is the delaying party.
Implementations are encouraged and the protocol is appropriate for deployment in production systems, but some changes to the protocol are possible before it becomes a Final Standard.1. The room creator might send the complete one-to-one chat history before inviting additional users to the room, and also send as history any messages appearing in the one-to-one chat interface after joining the room and before the second person joins the room; if the one-to-one history is especially large, the sending client might want to send the history over a few seconds rather than all at once (to avoid triggering rate limits).