diff --git a/xep-0045.xml b/xep-0045.xml
index d5a77477..78a18bee 100644
--- a/xep-0045.xml
+++ b/xep-0045.xml
@@ -468,7 +468,6 @@
     <p>MUC -- the multi-user chat protocol for text-based conferencing specified in this document.</p>
     <p>Occupant -- any Jabber user who is in a room (this is an "abstract class" and does not correspond to any specific role).</p>
     <p>Outcast -- a user who has been banned from a room. An outcast has an affiliation of "outcast".</p>
-    <!-- <p>Outsider ... an unaffiliated user who is not in the room but who may interact with the room in certain limited ways. An outsider has a role of "outsider".</p> -->
     <p>Participant -- an occupant who does not have administrative privileges; in a moderated room, a participant is further defined as having voice (in contrast to a visitor). A participant has a role of "participant".</p>
     <p>Private Message -- a message sent from one occupant directly to another's room JID (not to the room itself for broadcasting to all occupants).</p>
     <p>Role -- 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.</p>
@@ -545,12 +544,6 @@
         <td>None</td>
         <td>N/A (the absence of a role)</td>
       </tr>
-      <!--
-      <tr>
-        <td>Outsider</td>
-        <td>OPTIONAL</td>
-      </tr>
-      -->
       <tr>
         <td>Participant</td>
         <td>REQUIRED</td>
@@ -571,7 +564,6 @@
         <tr>
           <th>Privilege</th>
           <th>None</th>
-          <!-- <th>Outsider</th> -->
           <th>Visitor</th>
           <th>Participant</th>
           <th>Moderator</th>
@@ -579,7 +571,6 @@
         <tr>
           <td>Present in Room</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -587,7 +578,6 @@
         <tr>
           <td>Receive Messages</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -595,7 +585,6 @@
         <tr>
           <td>Receive Occupant Presence</td>
           <td>No</td>
-          <!-- <td>Yes*</td> -->
           <td>Yes</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -603,7 +592,6 @@
         <tr>
           <td>Presence Broadcasted to Room</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes*</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -611,7 +599,6 @@
         <tr>
           <td>Change Availability Status</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -619,7 +606,6 @@
         <tr>
           <td>Change Room Nickname</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes*</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -627,7 +613,6 @@
         <tr>
           <td>Send Private Messages</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes*</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -635,7 +620,6 @@
         <tr>
           <td>Invite Other Users</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>Yes*</td>
           <td>Yes*</td>
           <td>Yes</td>
@@ -643,7 +627,6 @@
         <tr>
           <td>Send Messages to All</td>
           <td>No</td>
-          <!-- <td>No**</td> -->
           <td>No***</td>
           <td>Yes</td>
           <td>Yes</td>
@@ -651,7 +634,6 @@
         <tr>
           <td>Modify Subject</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>No*</td>
           <td>Yes*</td>
           <td>Yes</td>
@@ -659,7 +641,6 @@
         <tr>
           <td>Kick Participants and Visitors</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>No</td>
           <td>No</td>
           <td>Yes</td>
@@ -667,7 +648,6 @@
         <tr>
           <td>Grant Voice</td>
           <td>No</td>
-          <!-- <td>No</td> -->
           <td>No</td>
           <td>No</td>
           <td>Yes</td>
@@ -675,14 +655,12 @@
         <tr>
           <td>Revoke Voice</td>
           <td>No</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 SHOULD allow outsiders to receive the presence of room occupants and to send messages to the room.</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>
@@ -743,7 +721,6 @@
     <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 effectively register with an open room and thus be lastingly associated with that room in some way (one result may be that the user's nickname is reserved 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>An outsider is a user who may receive presence from room occupants and send messages to the room while not an occupant. A service should not send the outsider's presence to the room occupants or deliver room messages to the outsider.</p> -->
     <p>Information about affiliations MUST be sent in all presence stanzas generated or reflected by the room and sent to occupants.</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 privileges not possessed by the next-lowest affiliation; these privileges are specified in the following table.</p>
@@ -846,7 +823,6 @@
         </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>** Depending on the value of the "muc#roomconfig_getmemberlist" configuration option, an outsider MAY be allowed to retrieve the member list.</p> -->
       <p>** An admin or owner MUST NOT be able to revoke moderation privileges from another admin or owner.</p>
     </section3>
     <section3 topic='Changing Affiliations' anchor='affil-change'>
@@ -1060,7 +1036,7 @@
         <value>3</value>
       </field>
       <field var='muc#roominfo_ldapgroup' label='Associated LDAP Group'>
-        <value>Witches</value>
+        <value>dc=lit,dc=shakespeare,cn=witches</value>
       </field>
       <field var='muc#roominfo_lang' label='Language of discussion'>
         <value>en</value>
@@ -1170,156 +1146,6 @@
     ]]></code>
   </section2>
 </section1>
-<!--
-<section1 topic='Outsider Use Cases' anchor='outsider'>
-  <p>A service implementation MAY support the "outsider" role. This role enables an unaffiliated user who is not in the room to interact with the room in certain limited ways. The following settings and privileges are RECOMMENDED:</p>
-  <ul>
-    <li>An outsider SHOULD be allowed to send messages to all occupants of the room.</li>
-    <li>An outsider SHOULD be allowed to retrieve the list of room members.</li>
-    <li>An outsider SHOULD be allowed to see the presence of all occupants of the room.</li>
-    <li>An outsider SHOULD NOT receive messages sent to all occupants of the room.</li>
-    <li>An outsider SHOULD NOT have its presence broadcasted to the occupants of the room.</li>
-  </ul>
-  <p>The foregoing functionality is defined elsewhere in this document. This section describes special aspects of that functionality when applied to the outsider role.</p>
-  <section2 topic='Sending a Message' anchor='outsider-message'>
-    <p>When an outsider sends a message to all occupants of a room, the outsider is not "in" the room and therefore does not have a roomnick. Therefore the room MUST send the message from the JID of the room itself. In order for room occupants to reply to the message if desired, the message MUST include an indication of the sender's full JID, as illustrated in the following example.</p>
-    <example caption='Outsider Sends Message to Room'><![CDATA[
-<message
-    from='macbeth@shakespeare.lit/castle'
-    to='darkcave@macbeth.shakespeare.lit'
-    type='groupchat'>
-  <body>How now?</body>
-</message>
-    ]]></example>
-    <example caption='Room Reflects Message to all Occupants'><![CDATA[
-
-    from='macbeth@shakespeare.lit/castle'
-
-<message
-    from='darkcave@macbeth.shakespeare.lit'
-    to='crone1@shakespeare.lit/desktop'
-    type='groupchat'>
-  <body>How now?</body>
-  <x xmlns='http://jabber.org/protocol/muc#user'>
-    <item affiliation='none' 
-          jid='macbeth@shakespeare.lit/castle'
-          role='outsider'/>
-  </x>
-</message>
-<message
-    from='darkcave@macbeth.shakespeare.lit'
-    to='wiccarocks@shakespeare.lit/laptop'
-    type='groupchat'>
-  <body>How now?</body>
-  <x xmlns='http://jabber.org/protocol/muc#user'>
-    <item affiliation='none' 
-          jid='macbeth@shakespeare.lit/castle'
-          role='outsider'/>
-  </x>
-</message>
-<message
-    from='darkcave@macbeth.shakespeare.lit'
-    to='hag66@shakespeare.lit/pda'
-    type='groupchat'>
-  <body>How now?</body>
-  <x xmlns='http://jabber.org/protocol/muc#user'>
-    <item affiliation='none' 
-          jid='macbeth@shakespeare.lit/castle'
-          role='outsider'/>
-  </x>
-</message>
-    ]]></example>
-  </section2>
-  <section2 topic='Retrieving the Member List' anchor='outsider-memberlist'>
-    <p>An outsider can retrieve the member list by sending an IQ-get to the room containing a request for all users who have an affiliation of "member".</p>
-    <example caption='Outsider Requests Member List'><![CDATA[
-<iq from='macbeth@shakespeare.lit/castle'
-    id='getmembers1'
-    to='darkcave@macbeth.shakespeare.lit'
-    type='get'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item affiliation='member'/>
-  </query>
-</iq>
-    ]]></example>
-    <p>If the outsider is allowed to retrieve the member list, the room shall return the list, where the 'jid' attribute shows the bare JIDs of the members (and without including the 'nick' and 'role' attributes).</p>
-    <example caption='Service Sends Member List to Outsider'><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
-    id='getmembers'
-    to='macbeth@shakespeare.lit/castle'
-    type='result'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item affiliation='member' jid='hag66@shakespeare.lit'/>
-    <item affiliation='member' jid='wiccarocks@shakespeare.lit'/>
-  </query>
-</iq>
-    ]]></example>
-    <p>If the outsider is not allowed to retrieve the member list, the room shall return an error of &forbidden;.</p>
-    <example caption='Service Returns Forbidden Error'><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
-    id='getmembers'
-    to='macbeth@shakespeare.lit/castle'
-    type='error'>
-  <error code='403' type='auth'>
-    <forbidden xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
-  </error>
-</iq>
-    ]]></example>
-  </section2>
-  <section2 topic='Receiving Occupant Presence' anchor='outsider-presence'>
-    <p>In order to receive presence from the room occupants, an outsider sends presence to the room's JID with no resource:</p>
-    <example caption='Occupant Sends Presence to Room'><![CDATA[
-<presence
-    from='macbeth@shakespeare.lit/castle'
-    to='darkcave@macbeth.shakespeare.lit'>
-  <c xmlns='http://jabber.org/protocol/caps' 
-     hash='sha-1'
-     node='http://exodus.jabberstudio.org/#0.9.1'
-     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
-</presence>
-    ]]></example>
-    <example caption='Room Sends Presence of Occupants to Outsider'><![CDATA[
-<presence from='darkcave@macbeth.shakespeare.lit/firstwitch' to='macbeth@shakespeare.lit/castle'>
-  <c xmlns='http://jabber.org/protocol/caps' 
-     hash='sha-1'
-     node='http://psi-im.org/#0.11'
-     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
-  <x xmlns='http://jabber.org/protocol/muc#user'>
-    <item affiliation='owner' 
-          jid='crone1@shakespeare.lit/desktop'
-          role='moderator'/>
-  </x>
-</presence>
-
-<presence from='darkcave@macbeth.shakespeare.lit/secondwitch' to='macbeth@shakespeare.lit/castle'>
-  <c xmlns='http://jabber.org/protocol/caps' 
-     hash='sha-1'
-     node='http://exodus.jabberstudio.org/#0.9.1'
-     ver='8RovUdtOmiAjzj+xI7SK5BCw3A8='/>
-  <x xmlns='http://jabber.org/protocol/muc#user'>
-    <item affiliation='admin' 
-          jid='wiccarocks@shakespeare.lit/laptop'
-          role='moderator'/>
-  </x>
-</presence>
-
-<presence from='darkcave@macbeth.shakespeare.lit/thirdwitch' to='macbeth@shakespeare.lit/castle'>
-  <c xmlns='http://jabber.org/protocol/caps' 
-     hash='sha-1'
-     node='http://www.chatopus.com/#2.2'
-     ver='zHyEOgxTrkpSdGcQKH8EFPLsriY='/>
-  <x xmlns='http://jabber.org/protocol/muc#user'>
-    <item affiliation='member' 
-          jid='hag66@shakespeare.lit/laptop'
-          role='participant'/>
-  </x>
-</presence>
-
-[ ... ]
-    ]]></example>
-  </section2>
-</section1>
--->
 <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'>
@@ -3353,91 +3179,6 @@
     <p>If the admin approves the registration request, the service shall register the user with the room.</p>
     <p>More advanced registration approval mechanisms (e.g., retrieving a list of registration requests using &xep0050; as is done in &xep0060;) are out of scope for this document.</p>
   </section2>
-  <!--
-  <section2 topic='Granting Outsider Status' anchor='grantoutsider'>
-    <p>An admin can grant outsider status to a user by changing the role associated with the user's bare JID to "outsider".</p>
-    <example caption='Admin Grants Outsider Status'><![CDATA[
-<iq from='crone1@shakespeare.lit/desktop'
-    id='outsider1'
-    to='darkcave@macbeth.shakespeare.lit'
-    type='set'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item role='outsider' jid='macbeth@shakespeare.lit'/>
-  </query>
-</iq>
-    ]]></example>
-    <p>The service MUST add the user to the outsider list and then inform the admin of success:</p>
-    <example caption='Service Informs Admin of Success'><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
-    id='outsider1'
-    to='crone1@shakespeare.lit/desktop'
-    type='result'/>
-    ]]></example>
-  </section2>
-  <section2 topic='Revoking Outsider Status' anchor='revokeoutsider'>
-    <p>An admin can revoke a user's outsider status by changing the user's role to "none":</p>
-    <example caption='Admin Revokes Outsider Status'><![CDATA[
-<iq from='crone1@shakespeare.lit/desktop'
-    id='outsider2'
-    to='darkcave@macbeth.shakespeare.lit'
-    type='set'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item role='none' jid='macbeth@shakespeare.lit'/>
-  </query>
-</iq>
-    ]]></example>
-    <p>The service MUST remove the user from the outsider list and then inform the moderator of success:</p>
-    <example caption='Service Informs Admin of Success'><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
-    id='outsider2'
-    to='crone1@shakespeare.lit/desktop'
-    type='result'/>
-    ]]></example>
-  </section2>
-  <section2 topic='Modifying the Outsider List' anchor='modifyoutsider'>
-    <p>The outsider list is a list of users who are allowed to interact with the room from the outside without having any other affiliation with the room. If a service allows unaffiliated users to interact with the room from outside, it SHOULD also allow affiliated users (i.e., members, admins, and owners) to do so.</p>
-    <example caption='Admin Requests Outsider List'><![CDATA[
-<iq from='crone1@shakespeare.lit/desktop'
-    id='outsider3'
-    to='darkcave@macbeth.shakespeare.lit'
-    type='get'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item role='outsider'/>
-  </query>
-</iq>
-    ]]></example>
-    <example caption='Service Sends Outsider List to Admin'><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
-    id='outsider3'
-    to='crone1@shakespeare.lit/desktop'
-    type='result'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item role='outsider' jid='shakespeare.lit'/>
-    <item role='outsider' jid='romeo@montague.lit'/>
-    <item role='outsider' jid='juliet@capulet.lit'/>
-  </query>
-</iq>
-    ]]></example>
-    <p>The admin MAY then modify the outsider list. In order to do so, the admin MUST send the changed items (i.e., only the "delta") to the service; each item MUST include the 'role' attribute (set to a value of "outsider" or "none") and 'jid' attribute but SHOULD NOT include the 'nick' attribute and MUST NOT include the 'affiliatino' attribute (which is used to manage affiliations such as member rather than the outsider role):</p>
-    <example caption='Admin Sends Modified Outsider List to Service'><![CDATA[
-<iq from='crone1@shakespeare.lit/desktop'
-    id='outsider4'
-    to='darkcave@macbeth.shakespeare.lit'
-    type='set'>
-  <query xmlns='http://jabber.org/protocol/muc#admin'>
-    <item role='none' jid='romeo@capulet.lit'/>
-  </query>
-</iq>
-    ]]></example>
-    <p>The service MUST modify the outsider list and then inform the admin of success:</p>
-    <example caption='Service Informs Admin of Success'><![CDATA[
-<iq from='darkcave@macbeth.shakespeare.lit'
-    id='outsider4'
-    to='crone1@shakespeare.lit/desktop'
-    type='result'/>
-    ]]></example>
-  </section2>
-  -->
 </section1>
 <section1 topic='Owner Use Cases' anchor='owner'>
   <p>Every room MUST have at least one owner, and that owner (or a successor) is a long-lived attribute of the room for as long as the room exists (e.g., the owner does not lose ownership on exiting a persistent room). This document assumes that the (initial) room owner is the individual who creates the room and that only a room owner has the right to change defining room configuration settings such as the room type. Ideally, room owners will be able to specify not only the room types (password-protected, members-only, etc.) but also certain attributes of the room as listed in the <link url='#reqs'>Requirements</link> section of this document. In addition, it would be good if an owner were able to specify the JIDs of other owners, but that shall be determined by the implementation.</p>