From 8be65c97ff060bb318fa51e4f554d35184d29fd4 Mon Sep 17 00:00:00 2001 From: Peter Saint-Andre Date: Thu, 15 Jul 2010 18:29:40 +0000 Subject: [PATCH] order of events git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4329 4b5297f7-1745-476d-ba37-a9c6900126ab --- xep-0045.xml | 14 ++++++++++++-- 1 file changed, 12 insertions(+), 2 deletions(-) diff --git a/xep-0045.xml b/xep-0045.xml index 9d326f18..01cc3392 100644 --- a/xep-0045.xml +++ b/xep-0045.xml @@ -1191,11 +1191,21 @@

The main actor in a multi-user chat environment is the occupant, who can be said to be located "in" a multi-user chat room and to participate in the discussions held in that room (for the purposes of this specification, participants and visitors are considered to be "mere" occupants, since they possess no administrative privileges). As will become clear, the protocol elements proposed in this document to fulfill the occupant use cases fall into three categories:

    -

  1. existing "groupchat 1.0" protocol for minimal functionality

    2. -

  2. straightforward applications of the "groupchat 1.0" protocol, for example to handle some of the errors related to new room types

    3. +

  3. the basic functionality for joining a room, exchanging messages with all occupants, etc. (supported by the "groupchat 1.0" protocol that preceded MUC)

    4. +

  4. straightforward additions to the basic functionality, such as handling of errors related to new room types

  5. additional protocol elements to handle functionality not covered by "groupchat 1.0" (room invites, room passwords, extended presence related to room roles and affiliations); these are qualified by the 'http://jabber.org/protocol/muc#user' namespace

Note: All client-generated examples herein are presented from the perspective of the service, with the result that all stanzas received by a service contain a 'from' attribute corresponding to the sender's full JID as added by a normal XMPP router or session manager. In addition, normal IQ result stanzas sent upon successful completion of a request (as required by &rfc3920;) are not shown.

+ +

The order of events involved in joining a room needs to be consistent so that clients can know which events to expect when. After a client sends presence to join a room, the MUC service MUST send it events in the following order:

+
    +
  1. In-room presence from other occupants
    2. +
  2. In-room presence from the joining entity itself (so-called "self-presence")
    3. +
  3. Room history (if any)
    4. +
  4. The room subject (if any)
    5. +
  5. Live messages, presence updates, new user joins, etc.
    6. +
+

In order to participate in the discussions held in a multi-user chat room, a user MUST first become an occupant by entering the room. In the old "groupchat 1.0" protocol, this was done by sending presence to &ROOMJID;, where "room" is the room ID, "service" is the hostname of the chat service, and "nick" is the user's desired nickname within the room: