forked from xsf/xeps
-
Notifications
You must be signed in to change notification settings - Fork 0
/
xep-0045.xml
6103 lines (5885 loc) · 320 KB
/
xep-0045.xml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE xep SYSTEM 'xep.dtd' [
<!ENTITY % ents SYSTEM 'xep.ent'>
%ents;
<!ENTITY ROOMJID "<room@service>">
<!ENTITY OCCUPANTJID "<room@service/nick>">
]>
<?xml-stylesheet type='text/xsl' href='xep.xsl'?>
<xep>
<header>
<title>Multi-User Chat</title>
<abstract>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). 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.</abstract>
&LEGALNOTICE;
<number>0045</number>
<status>Draft</status>
<type>Standards Track</type>
<sig>Standards</sig>
<dependencies>
<spec>XMPP Core</spec>
<spec>XMPP IM</spec>
<spec>XEP-0004</spec>
<spec>XEP-0030</spec>
<spec>XEP-0068</spec>
<spec>XEP-0082</spec>
<spec>XEP-0128</spec>
</dependencies>
<supersedes/>
<supersededby/>
<shortname>muc</shortname>
<schemaloc>
<ns>muc</ns>
<url>http://www.xmpp.org/schemas/muc.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#admin</ns>
<url>http://www.xmpp.org/schemas/muc-admin.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#owner</ns>
<url>http://www.xmpp.org/schemas/muc-owner.xsd</url>
</schemaloc>
<schemaloc>
<ns>muc#user</ns>
<url>http://www.xmpp.org/schemas/muc-user.xsd</url>
</schemaloc>
<registry/>
&stpeter;
<revision>
<version>1.29</version>
<date>2017-09-01</date>
<initials>gl</initials>
<remark>
<p>Clarify wording for a client re-syncing to a MUC</p>
</remark>
</revision>
<revision>
<version>1.28</version>
<date>2017-05-31</date>
<initials>gl</initials>
<remark>
<p>Introduce <x/> tag in MUC-PMs to support better Carbon delivery.</p>
</remark>
</revision>
<revision>
<version>1.27.1</version>
<date>2016-12-03</date>
<initials>XEP Editor: ssw</initials>
<remark>
<p>Editorial typo and whitespace fixes.</p>
</remark>
</revision>
<revision>
<version>1.27</version>
<date>2016-10-29</date>
<initials>XEP Editor: ssw</initials>
<remark>
<ul>
<li>Clarify behavior on MUC join.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.26</version>
<date>2016-05-16</date>
<initials>XEP Editor (ssw)</initials>
<remark>
<ul>
<li>Add status code to self-presence example.</li>
<li>muc#roomconfig_allowpm should be list-single.</li>
<li>muc#roomconfig_allowinvites should be boolean.</li>
<li>Typo: Publish-Subscribe.</li>
<li>15.6.2 Initial Submission: Status code 174 is missing.</li>
<li>muc#role should be list-single</li>
<li>muc#register_faqentry: mixed occurrences of text-single and text-multi</li>
</ul>
</remark>
</revision>
<revision>
<version>1.25</version>
<date>2012-02-08</date>
<initials>psa</initials>
<remark>
<ul>
<li>Clarified the fact that room roles and affiliations are shortcuts to bundles of privileges.</li>
<li>Removed references to service discovery feature for "gc-1.0" since it is now obsolete.</li>
<li>Added security consideration about information leaks related to service discovery.</li>
<li>Corrected some examples of presence and message errors so that the 'from' and 'to' addresses are merely swapped, in accordance with RFC 6120; also added 'by' attribute to show that the room itself generated the error.</li>
<li>Added 'nick' attribute to <actor/> element so that an action can be attributed either to a real JID or to a roomnick.</li>
<li>Clarified the meaning of status code 100.</li>
<li>Corrected delayed delivery text and examples so that the 'from' address is that of the room, and specified optional inclusion of the XEP-0033 'ofrom' address to note original sender.</li>
<li>Added 'id' attributes to most examples, especially message and presence stanzas generated by the room since IDs can be used for tracking purposes and ghost detection.</li>
<li>Added term "Occupant JID" to differentiate between the JID of a <room@service> and the JID of a <room@service/nick>.</li>
<li>Added "muc#maxhistoryfetch" form field.</li>
<li>Loosened handling of room joins when nicks are locked down, so that the service should modify the roomnick instead of returning an error.</li>
<li>Specified that the room must return a room subject, even if the subject is empty.</li>
<li>Removed feature for requesting a unique room name (the client can simply use a UUID).</li>
<li>Removed any mention of fully-anonymous rooms, which are not supported by this specification.</li>
<li>Clarified many small points in the text and examples.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.24</version>
<date>2008-07-16</date>
<initials>psa</initials>
<remark><p>Added more examples of the reason element; removed mention of nick inclusion with regard to ban lists; added denial of service considerations.</p></remark>
</revision>
<revision>
<version>1.23</version>
<date>2008-01-14</date>
<initials>psa</initials>
<remark>
<ul>
<li>Defined getmemberlist room configuration option</li>
<li>Added direct invitation protocol</li>
<li>Corrected logic regarding admission of room owner/admin when room is full</li>
<li>Defined service discovery extension field for associated LDAP group</li>
<li>Specified that room config fields can be listed in extended room information</li>
<li>Specified message format for affiliation change notifications if user is not in the room</li>
<li>Added example showing use of Result Set Management</li>
<li>Recommended inclusion of MUC child element in presence errors</li>
<li>Described use of ThreadID for continuity between one-to-one chat and multi-user chat, including definition of thread attribute for continue element in invitations.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.22</version>
<date>2007-04-10</date>
<initials>psa</initials>
<remark><p>Updated delayed delivery reference to reflect advancement of XEP-0203 to Draft and deprecation of XEP-0091.</p></remark>
</revision>
<revision>
<version>1.21</version>
<date>2006-09-13</date>
<initials>psa</initials>
<remark>
<ul>
<li>Clarified that inclusion of MUC extension in room join/create request triggers Data Forms flow but that absence of MUC extension leads to automatic room creation for backwards compatibility with older groupchat 1.0 protocol.</li>
<li>Specified use of <not-acceptable/> error on nickname change if nicks are locked down.</li>
<li>Required clients to discover room configuration prior to entering room and specified related security considerations, including use of privacy-related status codes 170, 171, 172, 173, and 174.</li>
<li>Specified use of <not-acceptable/> error if room configuration options cannot be processed or violate service policies.</li>
<li>Made explicit that roomnicks must not consist only of spaces.</li>
<li>Moved all service discovery use cases into dedicated section.</li>
<li>Changed urn:xmpp:delay support from SHOULD to MUST.</li>
<li>Clarified that _whois room configuration option specifies room type.</li>
<li>Defined XEP-0128 room information fields for discussion logs, associated pubsub node, and contact JID.</li>
<li>Specified that changing role to moderator upon affiliation change to admin or owner is recommended, not required.</li>
<li>Added internationalization consideration about localization of field labels for various data forms.</li>
<li>Specified that implementations may persist roles across visits and should do so for moderated rooms.</li>
<li>Added protocol and service discovery feature for requesting a unique room name prior to room creation.</li>
<li>Further clarified nature of reserved room nicknames and nickname lockdown.</li>
<li>Defined data forms for requesting voice and approving voice requests.</li>
<li>Added multiple invitee example for XMPP URI.</li>
<li>Clarified order of presence, discussion history, etc.</li>
<li>Added status codes for occupant's own roomnick, service-modified roomnick, and warning that room discussion is publicly logged.</li>
<li>Clarified privacy and anonymity considerations regarding room logging and non-anonymous rooms.</li>
</ul>
</remark>
</revision>
<revision>
<version>1.20</version>
<date>2005-09-08</date>
<initials>psa</initials>
<remark><p>Harmonized ability to kick and ban users, and clarified that a user cannot be kicked or banned by a moderator or admin with a lower affiliation.</p></remark>
</revision>
<revision>
<version>1.19</version>
<date>2005-04-21</date>
<initials>psa</initials>
<remark><p>Specified how to send multiple invitations simultaneously; corrected some errors regarding consistency of affiliation state changes; changed message events prohibition from MUST NOT to SHOULD NOT; corrected error handling related to the #traffic disco node; allowed <password/> as a child of <destroy/>; changed max users error from ¬allowed; to &unavailable;; specified that the maxchars attribute counts characters in complete XML stanzas; added disco features for FORM_TYPEs; defined registry for status codes; split Create Instant Room into separate use case for protocol compliance purposes; adjusted XML schemas to reflect the foregoing changes; re-wrote the introduction; clarified small textual matters throughout.</p></remark>
</revision>
<revision>
<version>1.18</version>
<date>2004-11-02</date>
<initials>psa</initials>
<remark><p>Corrected several errors in the affiliation state chart and in the examples (wrong FORM_TYPE values); mentioned /me command.</p></remark>
</revision>
<revision>
<version>1.17</version>
<date>2004-10-04</date>
<initials>psa</initials>
<remark><p>Added text about allowable extension namespaces and related service discovery mechanisms; specified well-known service discovery nodes; added conformance terms to clarify some descriptions; modified affiliation state chart to allow more flexible state changes; per list dicussion, added ability to convert a one-to-one chat into a conference, including sending of history; specified error to use when max users limit is reached; specified form for admin approval of user registration requests and modified FORM_TYPE from http://jabber.org/protocol/muc#user to http://jabber.org/protocol/muc#register; modified FORM_TYPE for room configuration from http://jabber.org/protocol/muc#owner to http://jabber.org/protocol/muc#roomconfig.</p></remark>
</revision>
<revision>
<version>1.16</version>
<date>2004-06-30</date>
<initials>psa</initials>
<remark><p>Added example and registry submission for service discovery extension.</p></remark>
</revision>
<revision>
<version>1.15</version>
<date>2004-06-24</date>
<initials>psa</initials>
<remark><p>Removed jabber:iq:browse references; clarified order of presence stanzas sent to new occupant on entering room; specified format of in-room messages (type='groupchat', from='room@service'); clarified allowable attributes in various list-related operations; made admin/owner revocation text and examples consistent with state chart; clarified ownership revocation conflict scenarios; changed the 'muc#roomconfig_inviteonly' field to 'muc#roomconfig_membersonly'; changed attribute order in examples to match XML canonicalization rules; corrected several errors in the schemas.</p></remark>
</revision>
<revision>
<version>1.14</version>
<date>2004-05-03</date>
<initials>psa</initials>
<remark><p>Corrected discovery of registered roomnicks; added note about error to return if nicks are locked down.</p></remark>
</revision>
<revision>
<version>1.13</version>
<date>2004-03-31</date>
<initials>psa</initials>
<remark><p>Fixed an error in the muc#user schema.</p></remark>
</revision>
<revision>
<version>1.12</version>
<date>2004-03-01</date>
<initials>psa</initials>
<remark><p>Corrected a few errors in the examples; added IQ results in order to clarify workflows.</p></remark>
</revision>
<revision>
<version>1.11</version>
<date>2004-02-05</date>
<initials>psa</initials>
<remark><p>Clarified JID matching rules (same as for privacy lists in XMPP IM).</p></remark>
</revision>
<revision>
<version>1.10</version>
<date>2004-01-07</date>
<initials>psa</initials>
<remark><p>Added XMPP error handling; fully specified all conformance terms.</p></remark>
</revision>
<revision>
<version>1.9</version>
<date>2003-12-14</date>
<initials>psa</initials>
<remark><p>Removed protocol for requesting voice in a moderated room (should be performed using Ad-Hoc Commands).</p></remark>
</revision>
<revision>
<version>1.8</version>
<date>2003-12-04</date>
<initials>psa</initials>
<remark><p>Added protocol for requesting voice in a moderated room; added (informational) mapping of IRC commands to MUC protocols.</p></remark>
</revision>
<revision>
<version>1.7</version>
<date>2003-10-21</date>
<initials>psa</initials>
<remark><p>Added room configuration option for restricting presence broadcast to certain roles.</p></remark>
</revision>
<revision>
<version>1.6</version>
<date>2003-10-03</date>
<initials>psa</initials>
<remark><p>Added history management protocol on entering a room.</p></remark>
</revision>
<revision>
<version>1.5</version>
<date>2003-09-11</date>
<initials>psa</initials>
<remark><p>Specified that ban occurs by JID, not roomnick; allowed privileged users to send messages to the room even if not present in the room; added note that service should remove occupant if a delivery-related stanza error occurs; enabled user to disco the room in order to discover registered roomnick; specified that "banning" by domain or regex is a service-level configuration matter and therefore out of scope for MUC; specified that role should be decremented as appropriate if affiliation is lowered; added some clarifying text to room creation workflow; added implementation note about sending an out-of-band message if a user's affiliation changes while the user is not in the room; fixed stringprep references (room nicks use Resourceprep); clarified relationship between Room ID (i.e., node identifier of Room JID or Occupant JID, which may be opaque) and natural-language Room Name; specified Field Standardization profile per XEP-0068; defined XMPP Registrar submissions; added schema locations.</p></remark>
</revision>
<revision>
<version>1.4</version>
<date>2003-02-16</date>
<initials>psa</initials>
<remark><p>Added XML schemas.</p></remark>
</revision>
<revision>
<version>1.3</version>
<date>2003-02-11</date>
<initials>psa</initials>
<remark><p>Added reference to nodeprep Internet-Draft.</p></remark>
</revision>
<revision>
<version>1.2</version>
<date>2003-01-30</date>
<initials>psa</initials>
<remark><p>Commented out revision history prior to version 1.0 (too long); clarified business rules regarding when nicks, full JIDs, and bare JIDs are used in reference to roles and affiliations; consistently specified that extended presence information in the muc#user namespace must include the full JID as the value of the 'jid' attribute in all cases; cleaned up text and examples throughout; added open issue regarding syntax of room nicknames.</p></remark>
</revision>
<revision>
<version>1.1</version>
<date>2002-12-16</date>
<initials>psa</initials>
<remark><p>Added protocol for declining an invitation; replaced <created/> element with status code 201; modified the destroy room protocol so that <destroy/> is a child of <query/>; clarified usage of 'nick' attribute when adding members; prohibited use of message events.</p></remark>
</revision>
<revision>
<version>1.0</version>
<date>2002-11-21</date>
<initials>psa</initials>
<remark><p>Per a vote of the Jabber Council, revision 0.23 was advanced to Draft on 2002-11-21. (For earlier revision history, refer to XML source.)</p></remark>
</revision>
<revision>
<version>0.23</version>
<date>2002-11-06</date>
<initials>psa</initials>
<remark><p>Added examples for disco#items queries sent to a room; prohibited 'type' attribute on invite messages sent from client to room; added dependencies on browse and disco; changed 'room user' to 'occupant'; fixed many small errors throughout.</p></remark>
</revision>
<revision>
<version>0.22</version>
<date>2002-11-04</date>
<initials>psa</initials>
<remark><p>Added example for disco#items; added support for cancellation of room configuration using type='cancel' from XEP-0004; noted 403 error for invites sent by non-admins in members-only room.</p></remark>
</revision>
<revision>
<version>0.21</version>
<date>2002-11-01</date>
<initials>psa</initials>
<remark><p>Clarified several small ambiguities; made <body/> optional on invites sent from the service to the invitee; added error scenarios for changing nickname and for destroying the room; specified that the service must return the full member list for a members-only room (not only the members in the room); updated the disco examples to track protocol changes.</p></remark>
</revision>
<revision>
<version>0.20</version>
<date>2002-10-29</date>
<initials>psa</initials>
<remark><p>Specified that messages sent to change the room subject must be of type "groupchat"; updated the legal notice to conform to the XSF IPR policy.</p></remark>
</revision>
<revision>
<version>0.19</version>
<date>2002-10-28</date>
<initials>psa</initials>
<remark><p>Added ability to create an instant room within MUC (not by using gc-1.0 protocol); cleaned up disco examples.</p></remark>
</revision>
<revision>
<version>0.18</version>
<date>2002-10-27</date>
<initials>psa</initials>
<remark><p>Added experimental support for disco; added sections for security, IANA, and JANA considerations; corrected typographical errors; cleaned up some DocBook formatting.</p></remark>
</revision>
<revision>
<version>0.17</version>
<date>2002-10-23</date>
<initials>psa</initials>
<remark><p>Added the optional <actor/> element (with 'jid' attribute) to <item/> elements inside presence stanzas of type "unavailable" that are sent to users who are kicked or banned, as well as within IQs for tracking purposes; reverted all list editing use cases (ban, voice, member, moderator, admin, owner) to use of MUC format rather than 'jabber:x:data' namespace; added several guidelines regarding generation and handling of XML stanzas; cleaned up the change room subject use case; changed several ambiguous uses of 'would', 'can', and 'will' to 'should', 'may', or 'must'; fixed several small errors in the text, examples, and DTDs.</p></remark>
</revision>
<revision>
<version>0.16</version>
<date>2002-10-20</date>
<initials>psa</initials>
<remark><p>Added the <item/> element to presence stanzas of type "unavailable" in order to improve the tracking of user states in the room; consolidated <invitee/> and <inviter/> elements into an <invite/> element with 'from' and 'to' attributes; made <reason/> element always a child of <item/> or <invite/> in the muc#user namespace; moved the alternate room location in room destruction to a 'jid' attribute of the <alt/> element; further specified several error messages; disallowed simultaneous modifications of both affiliations and roles by a moderator or admin; added several more rules regarding handling of XML stanzas; added use cases for granting and revoking admin status; adjusted DTD to track all changes.</p></remark>
</revision>
<revision>
<version>0.15</version>
<date>2002-10-18</date>
<initials>psa</initials>
<remark><p>Fully incorporated the change to affiliations + roles; moved a number of admin use cases to a new section for moderator use cases; added participant use case for requesting membership; added admin use cases for adding members, removing members, granting and revoking moderator status, and modifying the moderator list; organized the sections in a more logical manner.</p></remark>
</revision>
<revision>
<version>0.14</version>
<date>2002-10-17</date>
<initials>psa</initials>
<remark><p>Significantly modified the privileges model by distinguishing between in-room "roles" and long-lived "affiliations"; specified the privileges of the various roles and affiliations; included state transition charts for both roles and affiliations; removed use of MUC protocol for editing ban, voice, and admin lists (but not for the actions of banning users and granting/revoking voice); added delivery rule regarding IQ stanzas; changed kick so that the action is based on changing the role to "none".</p></remark>
</revision>
<revision>
<version>0.13</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark><p>Corrected the change nickname examples (newnick sent on unavailable, no nick sent on available).</p></remark>
</revision>
<revision>
<version>0.12</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark><p>Removed SHA1 passwords; specified that room shall add passwords on invitations to password-protected rooms (not supplied by inviter).</p></remark>
</revision>
<revision>
<version>0.11</version>
<date>2002-10-16</date>
<initials>psa</initials>
<remark><p>Changed 'participant' to 'room user' and 'discussant' to 'participant'; clarified presence rule about client generation of extended presence information; added role of 'none'.</p></remark>
</revision>
<revision>
<version>0.10</version>
<date>2002-10-15</date>
<initials>psa</initials>
<remark><p>Fixed extended presence on entering or creating a room (plain '...muc' with no fragment); harmonized #user with #admin regarding the use of the <item/> element and associated attributes (jid, nick, etc.), and added 'role' attribute; modified management of voice, ban, admin, and member lists to use <query/> wrapper and new <item/> structure; changed the 'member' role to 'discussant', added 'outcast' role for banned users, and added new 'member' role to enable management of member lists; changed invitation-only rooms to members-only rooms and made appropriate adjustments to apply member lists to both members-only rooms and open rooms; modified nickname change protocol slightly to send the old nickname in the unavailable presence and the new nickname in the available presence; removed prohibition on members-only rooms that are password-protected; removed the <query/> wrapper for the <destroy/> element; updated the DTDs.</p></remark>
</revision>
<revision>
<version>0.9</version>
<date>2002-10-13</date>
<initials>psa</initials>
<remark><p>Added extended presence ('...#user') on entering a room for MUC clients; changed namespace on room creation request to '...#owner'; added a service discovery example using jabber:iq:browse; added information about discussion history; made small fixes to several examples; further defined the presence rules; transferred all implementation notes to a dedicated section; added a Terminology section.</p></remark>
</revision>
<revision>
<version>0.8</version>
<date>2002-10-10</date>
<initials>psa</initials>
<remark><p>Made further changes to the room creation workflow (finally correct); removed feature discovery use case (this needs to be addressed by a real service discovery protocol!); added ability for room owners to edit the admin list; removed <body/> from invitations generated by the service; removed messages sent to kicked and banned users (handled by unavailable presence with status code); added a number of implementation notes; converted all examples to Shakespeare style.</p></remark>
</revision>
<revision>
<version>0.7.6</version>
<date>2002-10-09</date>
<initials>psa</initials>
<remark><p>Fixed the room creation workflow; changed some terminology ("join" to "enter" and "leave" to "exit").</p></remark>
</revision>
<revision>
<version>0.7.5</version>
<date>2002-10-08</date>
<initials>psa</initials>
<remark><p>Specified and improved the handling of invitation-only rooms. In particular, added the ability for room admins to edit the invitation list and added a configuration option that limits the ability to send invitations to room admins only.</p></remark>
</revision>
<revision>
<version>0.7.4</version>
<date>2002-10-07</date>
<initials>psa</initials>
<remark><p>Changed namespaces from http://jabber.org/protocol/muc/owner etc. to http://jabber.org/protocol/muc#owner etc. per Jabber Council discussion.</p></remark>
</revision>
<revision>
<version>0.7.3</version>
<date>2002-10-07</date>
<initials>psa</initials>
<remark><p>Changed namespaces to HTTP URIs; left role handling up to the implementation; further clarified presence rules.</p></remark>
</revision>
<revision>
<version>0.7.2</version>
<date>2002-10-06</date>
<initials>psa</initials>
<remark><p>Disallowed kicking, banning, and revoking voice with respect to room admins and room owners; replaced <x/> with <query/> in the Discovering Room Features and Destroying a Room use cases; corrected some small errors and made many clarifications throughout.</p></remark>
</revision>
<revision>
<version>0.7.1</version>
<date>2002-10-04</date>
<initials>psa</initials>
<remark><p>Removed <whois/> command (unnecessary since participants with appropriate privileges receive the full JID of all participants in presence stanzas); completed many small fixes throughout.</p></remark>
</revision>
<revision>
<version>0.7</version>
<date>2002-10-03</date>
<initials>psa</initials>
<remark><p>More clearly delineated participant roles and defined the hierarchy thereof (owner, admin, member, visitor); replaced <voice/> element in extended presence with <item role='member'/>; changed initial room configuration to use IQ rather than message; adjusted presence rules (especially regarding extended presence information); cleaned up examples throughout; updated DTD to track changes.</p></remark>
</revision>
<revision>
<version>0.6</version>
<date>2002-09-21</date>
<initials>psa</initials>
<remark><p>More clearly defined the scope; removed fully anonymous rooms; changed meaning of semi-anonymous rooms and of non-anonymous rooms; added mechanism for notification of full JIDs in non-anonymous rooms; replaced the <admin/> element in extended presence with a <role/> element (more extensible); changed room passwords to cleartext; added status codes for various messages received from the service; added lists of valid error and status codes associated with the 'http://jabber.org/protocol/muc#user' namespace; added a <reason/> element for invitations; made kick and ban reasons child elements rather than attributes; replaced stopgap feature discovery mechanism with jabber:iq:negotiate; added extended presence element to room creation request and clarified the room creation process; specified presence reflection rules; added method for destroying a room; adjusted DTDs to track all changes.</p></remark>
</revision>
<revision>
<version>0.5.1</version>
<date>2002-09-20</date>
<initials>psa</initials>
<remark><p>Added DTDs; changed feature discovery to use <x/> element rather than query and made service response come in IQ result; fixed reference to JID spec; changed 'grant' to 'add' and 'revoke' to 'remove' for consistency in the item attributes; made several other small changes.</p></remark>
</revision>
<revision>
<version>0.5</version>
<date>2002-09-19</date>
<initials>psa</initials>
<remark><p>Changed the kick, ban, and voice protocols; added a few more configuration options; specified the restrictions for roomnicks; and added a stopgap service discovery protocol.</p></remark>
</revision>
<revision>
<version>0.4</version>
<date>2002-09-18</date>
<initials>psa</initials>
<remark><p>Changed all non-groupchat-1.0 use cases to jabber:gc:* namespaces or jabber:x:data; added use cases for ban list management and room moderation; added protocol for sending notice of admin and voice privileges in presence; cleaned up text and many examples.</p></remark>
</revision>
<revision>
<version>0.3</version>
<date>2002-09-17</date>
<initials>psa</initials>
<remark><p>Changed admin use cases; cleaned up participant and owner use cases.</p></remark>
</revision>
<revision>
<version>0.2</version>
<date>2002-09-12</date>
<initials>psa</initials>
<remark><p>Broke content out into three actors (participant, owner, and admin) and added more detail to owner and admin use cases.</p></remark>
</revision>
<revision>
<version>0.1</version>
<date>2002-09-09</date>
<initials>psa</initials>
<remark><p>Initial version.</p></remark>
</revision>
</header>
<section1 topic='Introduction' anchor='intro'>
<p>Traditionally, instant messaging is thought to consist of one-to-one chat rather than many-to-many chat, which is called variously "groupchat" or "text conferencing". Groupchat functionality is familiar from systems such as Internet Relay Chat (IRC) and the chatroom functionality offered by popular consumer IM services. The Jabber/XMPP community developed and implemented a basic groupchat protocol as long ago as 1999. That "groupchat 1.0" (GC) protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification (Multi-User Chat or MUC) builds on the older groupchat 1.0 protocol in a backwards-compatible manner but provides advanced features such as invitations, room moderation and administration, and specialized room types.</p>
</section1>
<section1 topic='Scope' anchor='scope'>
<p>This document addresses common requirements related to configuration of, participation in, and administration of individual text-based conference rooms. All of the requirements addressed herein apply at the level of the individual room and are "common" in the sense that they have been widely discussed within the Jabber/XMPP community or are familiar from existing text-based conference environments (e.g., Internet Relay Chat as defined in &rfc1459; and its successors: &rfc2810;, &rfc2811;, &rfc2812;, &rfc2813;).</p>
<p>This document explicitly does <em>not</em> address the following:</p>
<ul>
<li>Relationships between rooms (e.g., hierarchies of rooms)</li>
<li>Management of multi-user chat services (e.g., managing permissions across an entire service or registering a global room nickname); such use cases are specified in &xep0133;</li>
<li>Moderation of individual messages</li>
<li>Encryption of messages sent through a room</li>
<li>Advanced features such as attaching files to a room, integrating whiteboards, and using MUC rooms as a way to manage the signalling for multi-user audio or video conferencing (see &xep0272;)</li>
<li>Interaction between MUC deployments and foreign chat systems (e.g., gateways to IRC or to legacy IM systems)</li>
<li>Mirroring or replication of rooms among multiple MUC deployments</li>
</ul>
<p>This limited scope is not meant to disparage such topics, which are of inherent interest; however, it is meant to focus the discussion in this document and to present a comprehensible protocol that can be implemented by client and service developers alike. Future specifications might address the topics mentioned above.</p>
</section1>
<section1 topic='Requirements' anchor='reqs'>
<p>This document addresses the minimal functionality provided by Jabber-based multi-user chat services that existed in 2002 when development of MUC began. For the sake of backwards-compatibility, this document uses the original groupchat 1.0 protocol for this baseline functionality, with the result that:</p>
<ul>
<li>Each room is identified as a "room JID" &ROOMJID; (e.g., <jdev@conference.jabber.org>), where "room" is the name of the room and "service" is the hostname at which the multi-user chat service is running.</li>
<li>Each occupant in a room is identified as an "occupant JID" &OCCUPANTJID;, where "nick" is the room nickname of the occupant as specified on entering the room or subsequently changed during the occupant's visit.</li>
<li>A user enters a room (i.e., becomes an occupant) by sending directed presence to &OCCUPANTJID;.</li>
<li>An occupant can change his or her room nickname and availability status within the room by sending presence information to <room@service/newnick>.</li>
<li>Messages sent within multi-user chat rooms are of a special type "groupchat" and are addressed to the room itself (room@service), then reflected to all occupants.</li>
<li>An occupant exits a room by sending presence of type "unavailable" to its current &OCCUPANTJID;.</li>
</ul>
<p>The additional features and functionality addressed in MUC include the following:</p>
<ol start='1'>
<li>native conversation logging (no in-room bot required)</li>
<li>enabling users to request membership in a room</li>
<li>enabling occupants to view an occupant's full JID in a non-anonymous room</li>
<li>enabling moderators to view an occupant's full JID in a semi-anonymous room</li>
<li>allowing only moderators to change the room subject</li>
<li>enabling moderators to kick participants and visitors from the room</li>
<li>enabling moderators to grant and revoke voice (i.e., the privilege to speak) in a moderated room, and to manage the voice list</li>
<li>enabling admins to grant and revoke moderator status, and to manage the moderator list</li>
<li>enabling admins to ban users from the room, and to manage the ban list</li>
<li>enabling admins to grant and revoke membership privileges, and to manage the member list for a members-only room</li>
<li>enabling owners to configure various room parameters (e.g., limiting the number of occupants)</li>
<li>enabling owners to specify other owners</li>
<li>enabling owners to grant and revoke admin status, and to manage the admin list</li>
<li>enabling owners to destroy the room</li>
</ol>
<p>In addition, this document provides protocol elements for supporting the following room types:</p>
<ol start='1'>
<li>public vs. hidden</li>
<li>persistent vs. temporary</li>
<li>password-protected vs. unsecured</li>
<li>members-only vs. open</li>
<li>moderated vs. unmoderated</li>
<li>non-anonymous vs. semi-anonymous</li>
</ol>
<p>The extensions needed to implement these requirements are qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).</p>
</section1>
<section1 topic='Terminology' anchor='terms'>
<section2 topic='General Terms' anchor='terms-general'>
<dl>
<di><dt>Affiliation</dt><dd>A long-lived association or connection with a room; the possible affiliations are "owner", "admin", "member", and "outcast" (naturally it is also possible to have no affiliation); affiliation is distinct from role. An affiliation lasts across a user's visits to a room.</dd></di>
<di><dt>Ban</dt><dd>To remove a user from a room such that the user is not allowed to re-enter the room (until and unless the ban has been removed). A banned user has an affiliation of "outcast".</dd></di>
<di><dt>Bare JID</dt><dd>The <user@host> by which a user is identified outside the context of any existing session or resource; contrast with Full JID and Occupant JID.</dd></di>
<di><dt>Full JID</dt><dd>The <user@host/resource> by which an online user is identified outside the context of a room; contrast with Bare JID and Occupant JID.</dd></di>
<di><dt>GC</dt><dd>The minimal "groupchat 1.0" protocol developed within the Jabber community in 1999; MUC is backwards-compatible with GC.</dd></di>
<di><dt>History</dt><dd>A limited number of message stanzas sent to a new occupant to provide the context of current discussion.</dd></di>
<di><dt>Invitation</dt><dd>A special message sent from one user to another asking the recipient to join a room; the invitation can be sent directly (see &xep0249;) or mediated through the room (as described under <link url='#invite'>Inviting Another User to a Room</link>).</dd></di>
<di><dt>IRC</dt><dd>Internet Relay Chat.</dd></di>
<di><dt>Kick</dt><dd>To temporarily remove a participant or visitor from a room; the user is allowed to re-enter the room at any time. A kicked user has a role of "none".</dd></di>
<di><dt>Logging</dt><dd>Storage of discussions that occur within a room for public retrieval outside the context of the room.</dd></di>
<di><dt>Member</dt><dd>A user who is on the "whitelist" for a members-only room or who is registered with an open room. A member has an affiliation of "member".</dd></di>
<di><dt>Moderator</dt><dd>A room role that is usually associated with room admins but that can be granted to non-admins; is allowed to kick users, grant and revoke voice, etc. A moderator has a role of "moderator".</dd></di>
<di><dt>MUC</dt><dd>The multi-user chat protocol for text-based conferencing specified in this document.</dd></di>
<di><dt>Multi-Session Nick</dt><dd>If allowed by the service, a user can associate more than one full JID with the same occupant JID (e.g., the user juliet@capulet.lit is allowed to log in simultaneously as the nick "JuliC" in the characters@chat.shakespeare.lit chatroom from both juliet@capulet.lit/balcony and juliet@capulet.lit/chamber). Multi-session nicks are not currently defined in this document.</dd></di>
<di><dt>Occupant</dt><dd>Any user who is in a room (this is an "abstract class" and does not correspond to any specific role).</dd></di>
<di><dt>Occupant JID</dt><dd>The <room@service/nick> by which an occupant is identified within the context of a room; contrast with Bare JID and Full JID.</dd></di>
<di><dt>Outcast</dt><dd>A user who has been banned from a room. An outcast has an affiliation of "outcast".</dd></di>
<di><dt>Participant</dt><dd>An occupant who does not have admin status; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</dd></di>
<di><dt>Private Message</dt><dd>A message sent from one occupant directly to another's occupant JID (not to the room itself for broadcasting to all occupants).</dd></di>
<di><dt>Role</dt><dd>A temporary position or privilege level within a room, distinct from a user's long-lived affiliation with the room; the possible roles are "moderator", "participant", and "visitor" (it is also possible to have no defined role). A role lasts only for the duration of an occupant's visit to a room.</dd></di>
<di><dt>Room</dt><dd>A virtual space that users figuratively enter in order to participate in real-time, text-based conferencing with other users.</dd></di>
<di><dt>Room Administrator</dt><dd>A user empowered by the room owner to perform administrative functions such as banning users; however, a room administrator is not allowed to change the room configuration or to destroy the room. An admin has an affiliation of "admin".</dd></di>
<di><dt>Room ID</dt><dd>The localpart of a Room JID, which might be opaque and thus lack meaning for human users (see under <link url='#bizrules'>Business Rules</link> for syntax); contrast with Room Name.</dd></di>
<di><dt>Room JID</dt><dd>The <room@service> address of a room.</dd></di>
<di><dt>Room Name</dt><dd>A user-friendly, natural-language name for a room, configured by the room owner and presented in Service Discovery queries; contrast with Room ID.</dd></di>
<di><dt>Room Nickname</dt><dd>The resourcepart of an Occupant JID (see <link url='#bizrules'>Business Rules</link> for syntax); this is the "friendly name" by which an occupant is known in the room.</dd></di>
<di><dt>Room Owner</dt><dd>The user who created the room or a user who has been designated by the room creator or owner as someone with owner status (if allowed); an owner is allowed to change the room configuration and destroy the room, in addition to all admin status. An owner has an affiliation of "owner".</dd></di>
<di><dt>Room Roster</dt><dd>A client's representation of the occupants in a room.</dd></di>
<di><dt>Server</dt><dd>An XMPP server that may or may not have associated with it a text-based conferencing service.</dd></di>
<di><dt>Service</dt><dd>A host that offers text-based conferencing capabilities; often but not necessarily a sub-domain of an XMPP server (e.g., conference.jabber.org).</dd></di>
<di><dt>Subject</dt><dd>A temporary discussion topic within a room.</dd></di>
<di><dt>Visit</dt><dd>A user's "session" in a room, beginning when the user enters the room (i.e., becomes an occupant) and ending when the user exits the room.</dd></di>
<di><dt>Visitor</dt><dd>In a moderated room, an occupant who does not have voice (in contrast to a participant). A visitor has a role of "visitor".</dd></di>
<di><dt>Voice</dt><dd>In a moderated room, the privilege to send messages to all occupants.</dd></di>
</dl>
</section2>
<section2 topic='Room Types' anchor='terms-rooms'>
<dl>
<di><dt>Hidden Room</dt><dd>A room that cannot be found by any user through normal means such as searching and service discovery; antonym: Public Room.</dd></di>
<di><dt>Members-Only Room</dt><dd>A room that a user cannot enter without being on the member list; antonym: Open Room.</dd></di>
<di><dt>Moderated Room</dt><dd>A room in which only those with "voice" are allowed to send messages to all occupants; antonym: Unmoderated Room.</dd></di>
<di><dt>Non-Anonymous Room</dt><dd>A room in which an occupant's full JID is exposed to all other occupants, although the occupant can request any desired room nickname; contrast with Semi-Anonymous Room.</dd></di>
<di><dt>Open Room</dt><dd>A room that non-banned entities are allowed to enter without being on the member list; antonym: Members-Only Room.</dd></di>
<di><dt>Password-Protected Room</dt><dd>A room that a user cannot enter without first providing the correct password; antonym: Unsecured Room.</dd></di>
<di><dt>Persistent Room</dt><dd>A room that is not destroyed if the last occupant exits; antonym: Temporary Room.</dd></di>
<di><dt>Public Room</dt><dd>A room that can be found by any user through normal means such as searching and service discovery; antonym: Hidden Room.</dd></di>
<di><dt>Semi-Anonymous Room</dt><dd>A room in which an occupant's full JID can be discovered by room admins only; contrast with Non-Anonymous Room.</dd></di>
<di><dt>Temporary Room</dt><dd>A room that is destroyed if the last occupant exits; antonym: Persistent Room.</dd></di>
<di><dt>Unmoderated Room</dt><dd>A room in which any occupant is allowed to send messages to all occupants; antonym: Moderated Room.</dd></di>
<di><dt>Unsecured Room</dt><dd>A room that anyone is allowed to enter without first providing the correct password; antonym: Password-Protected Room.</dd></di>
</dl>
</section2>
<section2 topic='Dramatis Personae' anchor='terms-personae'>
<p>Most of the examples in this document use the scenario of the witches' meeting held in a dark cave at the beginning of Act IV, Scene I of Shakespeare's <cite>Macbeth</cite>, represented here as the "coven@chat.shakespeare.lit" chatroom. The characters are as follows:</p>
<table caption='Dramatis Personae'>
<tr>
<th>Room Nickname</th>
<th>Full JID</th>
<th>Affiliation</th>
</tr>
<tr>
<td>firstwitch</td>
<td>crone1@shakespeare.lit/desktop</td>
<td>Owner</td>
</tr>
<tr>
<td>secondwitch</td>
<td>wiccarocks@shakespeare.lit/laptop</td>
<td>Admin</td>
</tr>
<tr>
<td>thirdwitch</td>
<td>hag66@shakespeare.lit/pda</td>
<td>None</td>
</tr>
</table>
</section2>
</section1>
<section1 topic='Roles, Affiliations, and Privileges' anchor='associations'>
<p>A user might be allowed to perform any number of actions in a room, from joining or sending a message to changing configuration options or destroying the room altogether. We call each permitted action a "privilege". There are two ways we might structure privileges:</p>
<ol>
<li><p>Define each privilege atomically and explicitly define each user's particular privileges; this is flexible but can be confusing to manage.</p></li>
<li><p>Define bundles of privileges that are generally applicable and assign a user-friendly "shortcut" to each bundle (e.g., "moderator" or "admin").</p></li>
</ol>
<p>MUC takes the second approach.</p>
<p>MUC also defines two different associations: long-lived affiliations and session-specific roles. These two association types are distinct from each other in MUC, since an affiliation lasts across visits, while a role lasts only for the duration of a visit. In addition, there is no one-to-one correspondence between roles and affiliations; for example, someone who is not affiliated with a room may be a (temporary) moderator, and a member may be a participant or a visitor in a moderated room. These concepts are explained more fully below.</p>
<section2 topic='Roles' anchor='roles'>
<p>The following roles are defined:</p>
<table caption='Roles'>
<tr>
<th>Name</th>
<th>Support</th>
</tr>
<tr>
<td>Moderator</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>None</td>
<td>N/A (the absence of a role)</td>
</tr>
<tr>
<td>Participant</td>
<td>REQUIRED</td>
</tr>
<tr>
<td>Visitor</td>
<td>RECOMMENDED</td>
</tr>
</table>
<p>Roles are temporary in that they do not necessarily persist across a user's visits to the room and MAY change during the course of an occupant's visit to the room. An implementation MAY persist roles across visits and SHOULD do so for moderated rooms (since the distinction between visitor and participant is critical to the functioning of a moderated room).</p>
<p>There is no one-to-one mapping between roles and affiliations (e.g., a member could be a participant or a visitor).</p>
<p>A moderator is the most powerful role within the context of the room, and can to some extent manage other occupants' roles in the room. A participant has fewer privileges than a moderator, although he or she always has the right to speak. A visitor is a more restricted role within the context of a moderated room, since visitors are not allowed to send messages to all occupants (depending on room configuration, it is even possible that visitors' presence will not be broadcasted to the room).</p>
<p>Roles are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. The privileges associated with these roles, as well as the actions that trigger changes in roles, are defined below.</p>
<p>Information about roles MUST be sent in all presence stanzas generated or reflected by the room and thus sent to occupants (if the room is configured to broadcast presence for a given role).</p>
<section3 topic='Privileges' anchor='roles-priv'>
<p>For the most part, roles exist in a hierarchy. For instance, a participant can do anything a visitor can do, and a moderator can do anything a participant can do. Each role has all the privileges possessed by the next-lowest role, plus additional privileges; these privileges are specified in the following table as defaults (an implementation MAY provide configuration options that override these defaults).</p>
<table caption='Privileges Associated With Roles'>
<tr>
<th>Privilege</th>
<th>None</th>
<th>Visitor</th>
<th>Participant</th>
<th>Moderator</th>
</tr>
<tr>
<td>Present in Room</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Receive Messages</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Receive Occupant Presence</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Broadcast Presence to All Occupants</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Change Availability Status</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Change Room Nickname</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Send Private Messages</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Invite Other Users</td>
<td>No</td>
<td>Yes*</td>
<td>Yes*</td>
<td>Yes</td>
</tr>
<tr>
<td>Send Messages to All</td>
<td>No</td>
<td>No**</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Modify Subject</td>
<td>No</td>
<td>No*</td>
<td>Yes*</td>
<td>Yes</td>
</tr>
<tr>
<td>Kick Participants and Visitors</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Grant Voice</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Revoke Voice</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes***</td>
</tr>
</table>
<p>* Default; configuration settings MAY modify this privilege.</p>
<p>** An implementation MAY grant voice by default to visitors in unmoderated rooms.</p>
<p>*** A moderator MUST NOT be able to revoke voice privileges from an admin or owner.</p>
</section3>
<section3 topic='Default Roles' anchor='roles-default'>
<p>The following table summarizes the initial default roles that a service SHOULD set based on the user's affiliation (there is no role associated with the "outcast" affiliation, since such users are not allowed to enter the room).</p>
<table caption='Initial Role Based on Affiliation'>
<tr>
<th>Room Type</th>
<th>None</th>
<th>Member</th>
<th>Admin</th>
<th>Owner</th>
</tr>
<tr>
<td>Moderated</td>
<td>Visitor</td>
<td>Participant</td>
<td>Moderator</td>
<td>Moderator</td>
</tr>
<tr>
<td>Unmoderated</td>
<td>Participant</td>
<td>Participant</td>
<td>Moderator</td>
<td>Moderator</td>
</tr>
<tr>
<td>Members-Only</td>
<td>N/A *</td>
<td>Participant</td>
<td>Moderator</td>
<td>Moderator</td>
</tr>
<tr>
<td>Open</td>
<td>Participant</td>
<td>Participant</td>
<td>Moderator</td>
<td>Moderator</td>
</tr>
</table>
<p>* Entry is not permitted.</p>
</section3>
<section3 topic='Changing Roles' anchor='roles-change'>
<p>The ways in which an occupant's role changes are well-defined. Sometimes the change results from the occupant's own action (e.g., entering or exiting the room), whereas sometimes the change results from an action taken by a moderator, admin, or owner. If an occupant's role changes, a MUC service implementation MUST change the occupant's role to reflect the change and communicate the change to all occupants (if the room is configured to broadcast presence from entities with a given role). Role changes and their triggering actions are specified in the following table.</p>
<table caption='Role State Chart'>
<tr>
<th>></th>
<th>None</th>
<th>Visitor</th>
<th>Participant</th>
<th>Moderator</th>
</tr>
<tr>
<td>None</td>
<td>--</td>
<td>Enter moderated room</td>
<td>Enter unmoderated room</td>
<td>Admin or owner enters room</td>
</tr>
<tr>
<td>Visitor</td>
<td>Exit room or be kicked by a moderator</td>
<td>--</td>
<td>Moderator grants voice</td>
<td>Admin or owner grants moderator status</td>
</tr>
<tr>
<td>Participant</td>
<td>Exit room or be kicked by a moderator</td>
<td>Moderator revokes voice</td>
<td>--</td>
<td>Admin or owner grants moderator status</td>
</tr>
<tr>
<td>Moderator</td>
<td>Exit room or be kicked by an admin or owner *</td>
<td>Admin or owner changes role to visitor *</td>
<td>Admin or owner changes role to participant or revokes moderator status *</td>
<td>--</td>
</tr>
</table>
<p>* A moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner).</p>
<p class='box'>Note: Certain roles are typically implicit in certain affiliations. For example, an admin or owner is automatically a moderator, so if an occupant is granted an affiliation of admin then the occupant will by that fact be granted a role of moderator; similarly, when an occupant is granted an affiliation of member in a moderated room, the occupant automatically has a role of participant. However, the loss of the admin affiliation does not necessarily mean that the occupant no longer has a role of moderator (since a "mere" occupant can be a moderator). Therefore, the role that is gained when an occupant is granted a certain affiliation is stable, whereas the role that is lost when an occupant loses a certain affilitation is not hardcoded and is left up to the implementation.</p>
</section3>
</section2>
<section2 topic='Affiliations' anchor='affil'>
<p>The following affiliations are defined:</p>
<ol start='1'>
<li>Owner</li>
<li>Admin</li>
<li>Member</li>
<li>Outcast</li>
<li>None (the absence of an affiliation)</li>
</ol>
<p>Support for the owner affiliation is REQUIRED. Support for the admin, member, and outcast affiliations is RECOMMENDED. (The "None" affiliation is the absence of an affiliation.)</p>
<p>These affiliations are long-lived in that they persist across a user's visits to the room and are not affected by happenings in the room. In addition, there is no one-to-one mapping between these affiliations and an occupant's role within the room. Affiliations are granted, revoked, and maintained based on the user's bare JID, not the nick as with roles.</p>
<p>If a user without a defined affiliation enters a room, the user's affiliation is defined as "none"; however, this affiliation does not persist across visits (i.e., a service does not maintain a "none list" across visits).</p>
<p>The member affiliation provides a way for a room owner or admin to specify a "whitelist" of users who are allowed to enter a members-only room. When a member enters a members-only room, his or her affiliation does not change, no matter what his or her role is. The member affiliation also provides a way for users to register with an open room and thus be lastingly associated with that room in some way (one result might be that the service could reserve the user's nickname in the room).</p>
<p>An outcast is a user who has been banned from a room and who is not allowed to enter the room.</p>
<p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants (if the room is configured to broadcast presence from entities with a given role).</p>
<section3 topic='Privileges' anchor='affil-priv'>
<p>For the most part, affiliations exist in a hierarchy. For instance, an owner can do anything an admin can do, and an admin can do anything a member can do. Each affiliation has all the privileges possessed by the next-lowest affiliation, plus additional privileges; these privileges are specified in the following table.</p>
<table caption='Privileges Associated With Affiliations'>
<tr>
<th>Privilege</th>
<th>Outcast</th>
<th>None</th>
<th>Member</th>
<th>Admin</th>
<th>Owner</th>
</tr>
<tr>
<td>Enter Open Room</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Register with Open Room</td>
<td>No</td>
<td>Yes</td>
<td>N/A</td>
<td>N/A</td>
<td>N/A</td>
</tr>
<tr>
<td>Retrieve Member List</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Enter Members-Only Room</td>
<td>No</td>
<td>No</td>
<td>Yes*</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Ban Members and Unaffiliated Users</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Edit Member List</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
<td>Yes</td>
</tr>
<tr>
<td>Assign and Remove Moderator Role</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes**</td>
<td>Yes**</td>
</tr>
<tr>
<td>Edit Admin List</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Edit Owner List</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Change Room Configuration</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
<tr>
<td>Destroy Room</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>No</td>
<td>Yes</td>
</tr>
</table>
<p>* As a default, an unaffiliated user enters a moderated room as a visitor, and enters an open room as a participant. A member enters a room as a participant. An admin or owner enters a room as a moderator.</p>
<p>** As noted, a moderator SHOULD NOT be allowed to revoke moderation privileges from someone with a higher affiliation than themselves (i.e., an unaffiliated moderator SHOULD NOT be allowed to revoke moderation privileges from an admin or an owner, and an admin SHOULD NOT be allowed to revoke moderation privileges from an owner).</p>
</section3>
<section3 topic='Changing Affiliations' anchor='affil-change'>
<p>The ways in which a user's affiliation changes are well-defined. Sometimes the change results from the user's own action (e.g., registering as a member of the room), whereas sometimes the change results from an action taken by an admin or owner. If a user's affiliation changes, a MUC service implementation MUST change the user's affiliation to reflect the change and communicate that to all occupants (if the room is configured to broadcast presence from entities with a given role). Affiliation changes and their triggering actions are specified in the following table.</p>
<table caption='Affiliation State Chart'>
<tr>
<th>></th>
<th>Outcast</th>
<th>None</th>
<th>Member</th>
<th>Admin</th>
<th>Owner</th>
</tr>
<tr>
<td>Outcast</td>
<td>--</td>
<td>Admin or owner removes ban</td>
<td>Admin or owner adds user to member list</td>
<td>Owner adds user to admin list</td>
<td>Owner adds user to owner list</td>
</tr>
<tr>
<td>None</td>