moparisthebest
/
xeps
mirror of https://github.com/moparisthebest/xeps
1
0
Fork 0
Code Issues Releases Wiki Activity

order of events 

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@4329 4b5297f7-1745-476d-ba37-a9c6900126ab
This commit is contained in:
Peter Saint-Andre 2010-07-15 18:29:40 +00:00
parent 32bb768d60
commit 8be65c97ff
1 changed files with 12 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
xep-0045.xml
View File

@ -1191,11 +1191,21 @@
<section1 topic='Occupant Use Cases' anchor='user'>
<p>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:</p>
<ol start='1'>
<li><p>existing "groupchat 1.0" protocol for minimal functionality</p></li>
<li><p>straightforward applications of the "groupchat 1.0" protocol, for example to handle some of the errors related to new room types</p></li>
<li><p>the basic functionality for joining a room, exchanging messages with all occupants, etc. (supported by the "groupchat 1.0" protocol that preceded MUC)</p></li>
<li><p>straightforward additions to the basic functionality, such as handling of errors related to new room types</p></li>
<li><p>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</p></li>
</ol>
<p>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.</p>
<section2 topic='Order of Events' anchor='order'>
<p>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:</p>
<ol>
<li>In-room presence from other occupants</li>
<li>In-room presence from the joining entity itself (so-called "self-presence")</li>
<li>Room history (if any)</li>
<li>The room subject (if any)</li>
<li>Live messages, presence updates, new user joins, etc.</li>
</ol>
</section2>
<section2 topic='Entering a Room' anchor='enter'>
<section3 topic='Groupchat 1.0 Protocol' anchor='enter-gc'>
<p>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:</p>