XEP-0045: Remove some more mentions of GC 1.0

The non-MUC way of joining a room has been removed in 1.32.0, but it
still was mentioned in a few places.  This removes cases which can’t
happen any longer.

xep-0045.xml

@@ -1514,21 +1514,7 @@
       <p>In this example, initial room presence is being sent from the new occupant (thirdwitch) to all occupants, including the new occupant.</p>
       <p>As shown in the last stanza, the "self-presence" sent by the room to the new user MUST include a status code of 110 so that the user knows this presence refers to itself as an occupant. This self-presence MUST NOT be sent to the new occupant until the room has sent the presence of all other occupants to the new occupant; this enables the new occupant to know when it has finished receiving the room roster.</p>
       <p>The service MAY rewrite the new occupant's roomnick (e.g., if roomnicks are locked down or based on some other policy).</p>
-      <p>In particular, if roomnicks are locked down then the service MUST do one of the following.</p>
-      <p>If the user has connected using a "groupchat 1.0" client (as indicated on joining the room by the lack of the MUC extension), then the service SHOULD deny the nickname change request and return a presence stanza of type "error" with a &notacceptable; error condition:</p>
-      <example caption='Service Denies Room Join Because Roomnicks Are Locked Down'><![CDATA[
-<presence
-    from='coven@chat.shakespeare.lit/thirdwitch'
-    id='ng91xs69'
-    to='hag66@shakespeare.lit/pda'
-    type='error'>
-  <x xmlns='http://jabber.org/protocol/muc'/>
-  <error by='coven@chat.shakespeare.lit' type='cancel'>
-    <not-acceptable xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
-  </error>
-</presence>
-]]></example>
-      <p>If the user has connected using a MUC client (as indicated on joining the room by inclusion of the MUC extension), then the service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
+      <p>The service MUST allow the client to enter the room, modify the nick in accordance with the lockdown policy, and include a status code of "210" in the presence broadcast that it sends to the new occupant.</p>
       <example caption="Service Sends New Occupant's Presence to New Occupant"><![CDATA[
 <presence
     from='coven@chat.shakespeare.lit/thirdwitch'
@@ -3807,7 +3793,7 @@
 
 <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. Room owners can 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, an owner can also specify the JIDs of other owners, if supported by the implementation.</p>
-  <p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>XEP-0004</cite>) are used for room configuration, triggered by use of the 'http://jabber.org/protocol/muc' namespace. If an entity does not include the MUC namespace in its room join/create request, then the service shall create the room and not wait for configuration via Data Forms before creating the room (this ensures backwards-compatibility with the old groupchat 1.0 protocol); however, if the room join/create request includes the MUC extension, then the service shall require configuration via Data Forms before creating and unlocking the room.</p>
+  <p>In order to provide the necessary flexibility for a wide range of configuration options, Data Forms (<cite>XEP-0004</cite>) are used for room configuration. The service shall require configuration via Data Forms before creating and unlocking the room.</p>
   <p>Note: The configuration options shown below address all of the features and room types listed in the requirements section of this document; however, the exact configuration options and form layout shall be determined by the implementation or specific deployment. Also, these are examples only and are not intended to define the only allowed or required configuration options for rooms. A given implementation or deployment MAY choose to provide additional configuration options (clearance levels, profanity filters, supported languages, message logging, etc.), which is why the use of the 'jabber:x:data' protocol is valuable here.</p>
   <section2 topic='Creating a Room' anchor='createroom'>
     <section3 topic='General Considerations' anchor='createroom-general'>
@@ -3861,7 +3847,6 @@
 </presence>
 ]]></example>
       <p>After receiving notification that the room has been created, the room owner needs to decide whether to accept the default room configuration (i.e., create an "instant room") or configure the room to use something other than the default room configuration (i.e., create a "reserved room"). The protocol flows for completing those two use cases are shown in the following sections.</p>
-      <p>Note: If the presence stanza sent to a nonexistent room does not include an &X; element qualified by the 'http://jabber.org/protocol/muc' namespace as shown above, the service SHOULD create a default room without delay (i.e., it MUST assume that the client supports groupchat 1.0 rather than MUC and therefore it MUST NOT lock the room while waiting for the room creator to either accept an instant room or configure a reserved room).</p>
     </section3>
 
     <section3 topic='Creating an Instant Room' anchor='createroom-instant'>