Remove Subject

xep-0369.xml

@@ -268,7 +268,7 @@
      </li>
     <li>&xep0313; (MAM) is used for all history access, with each node being individually addressable for MAM queries. This simplifies implementation compared to MUC (which had a specialized and rather limited history retrieval mechanism).</li>
     <li>A client can achieve a 'quick resync' of a node by requesting just those changes it has not yet received, using standard MAM protocol. This solves the old MUC issue of either receiving duplicate messages when rejoining a room or potentially missing messages.</li>
-    <li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them &mdash; e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:subject' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
+    <li>Because MAM is used for history, only those nodes that have a 'current value' need to store any items in them &mdash; e.g., 'urn:xmpp:mix:nodes:presence' and 'urn:xmpp:mix:nodes:information' would store their current values (with older values being queryable through MAM), while 'urn:xmpp:mix:nodes:messages' would store no items.</li>
     <li>A user's participation in a channel outlives their client sessions. A client which is offline will not share presence within the channel, but the associated user will still be listed as an participant. </li>
     <li>Presence is sent to all participants using bare JID, whether or not the user has an online client. </li>
     <li>Online clients MAY register presence, which is then shared with participants who have subscribed to presence.</li>
@@ -368,7 +368,6 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
       <tr><td>JID Map</td><td>'urn:xmpp:mix:nodes:jidmap'</td><td>For storing a list of anonymized bare JIDs from the participants node with a 1:1 mapping to the corresponding real JIDs.</td><td>Automatic</td><td>PubSub</td></tr>
       <tr><td>Presence</td><td>'urn:xmpp:mix:nodes:presence'</td><td>For storing information about the availability status of online participants, which MAY include multiple clients for a single participant.</td><td>Presence</td><td>Presence</td></tr>
       <tr><td>Information</td><td>'urn:xmpp:mix:nodes:info'</td><td>For storing general channel information, such as description. </td><td>PubSub</td><td>PubSub</td></tr>
-      <tr><td>Subject</td><td>'urn:xmpp:mix:nodes:subject'</td><td>For storing and sharing the current subject of a channel</td><td>Message</td><td>Message</td></tr>
       <tr><td>Allowed</td><td>'urn:xmpp:mix:nodes:allowed'</td><td>For storing JIDs that are allowed to be channel participants.</td><td>PubSub</td><td>PubSub</td></tr>
       <tr><td>Banned</td><td>'urn:xmpp:mix:nodes:banned'</td><td>For storing JIDs that are not allowed to be channel participants. </td><td>PubSub</td><td>PubSub</td></tr>
       <tr><td>Configuration</td><td>'urn:xmpp:mix:nodes:config'</td><td>For storing channel configuration. </td><td>PubSub</td><td>PubSub</td></tr>
@@ -471,9 +470,9 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         <tr><td>'Contact'</td><td>The JID or JIDs of the person or role responsible for the channel.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
       </table>
       <p>
-        Name and Description of the channel apply to the whole channel and are will usually be changed infrequently.   This contrasts to Subject, which is more likely to change frequently and will often reflect the topic being discussed which has narrower scope than channel as a whole.
+        Name and Description of the channel apply to the whole channel and are will usually be changed infrequently.   
       </p>
-      <p>The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject.  The format of the Information node follows &xep0004;.  This allows configuration to be updated by MIX defined commands and that the results of update commands are the same as the PubSub node.
+      <p>The name and description values MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the element.  The format of the Information node follows &xep0004;.  This allows configuration to be updated by MIX defined commands and that the results of update commands are the same as the PubSub node.
       The following example shows the format of a item in the information node for the example coven@mix.shakespeare.example channel.
       </p>
       <example caption="Information Node"><![CDATA[
@@ -498,23 +497,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 </items>
 ]]></example>
     </section3>
-    <section3 topic="Subject Node" anchor="subject-node">
+    
-      <p>The subject node publishes the current subject of channel. Subject history is stored in MAM. A single item is stored in this node at a time which MUST contain a "text" element and MAY contain additional text elements. Where multiple text elements are provided, each MUST posses an xml:lang attribute that describes the natural language of the subject.  </p>
-      <p>
-        Setting and sharing subject uses a message with subject element, in a manner compatible with &xep0045;.  Clients MAY also write or access this node using pubsub. Writes to this node will lead to update of subject by sending messages.   Setting the subject is controlled by configuration; in some channels it MAY be set by all users and in others restricted to administrators.
-        The following example shows the format of a item in the subject node.
-      </p>
-      <example caption="Subject Node">
-        <![CDATA[<items node='urn:xmpp:mix:nodes:subject'>
-  <item>
-    <text xml:lang="en">How to use Toads</text>
-    <text xml:lang="de">Wie benutzt man Kröten</text>
-  </item>
-</items>]]></example>
-      <p>
-        When a user subscribes to the Subject Node, this will cause the channel to send Subject messages to the user's server using the user's bare JID.  This is done on initial user subscription and on subject change.   Clients MAY directly read the channel subject from the Subject Node using PubSub.
-      </p>
-    </section3>
       <section3 topic="Allowed" anchor="allowed-node">
         <p>
           This node represents a list of JIDs that are allowed to become participants. If the allowed node is not present, all JIDs are allowed. This node is accessed and managed using standard pubsub.  The allowed list is always considered in conjunction with the banned list, stored in the banned node.  Only Administrators and Owners have write permission to the allowed node and are also the only roles that are allows to subscribe to this node.    Each item contains a real bare JID.  The following example shows how the allowed list can specify single JIDs and domains.
@@ -547,11 +530,11 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
         <tr><td>'Owner'</td><td>Bare JIDs with Owner rights as defined in ACL node.  When a channel is created, the JID creating the channel is configured as an owner, unless this attribute is explicitly configured to another value.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
         <tr><td>'Administrator'</td><td>Bare JIDs with Administrator rights.</td><td>jid-multi</td><td>-</td><td>-</td></tr>
         <tr><td>'End of Life'</td><td>The date and time at which the channel will be automatically removed by the server.   If this is not set, the channel is permanent.</td><td>text-single</td><td>-</td><td>-</td></tr>
-        <tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of  config nodes is implicit.  Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'subject'; 'information'; 'allowed'; 'banned'; 'avatar'</td><td>-</td></tr>
+        <tr><td>'Nodes Present'</td><td>Specifies which nodes are present. Presence of  config nodes is implicit.  Jidmap node MUST be present if participants node is present. 'avatar' means that both Avatar Data and Avatar Metadata nodes are present.</td><td>list-multi</td><td>'participants'; 'presence'; 'information'; 'allowed'; 'banned'; 'avatar'</td><td>-</td></tr>
         <tr><td>'Message Node Subscription'</td><td>Controls who can subscribe to messages node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
         <tr><td>'Presence Node Subscription'</td><td>Controls who can subscribe to presence node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
         <tr><td>'Participants Node Subscription'</td><td>Controls who can subscribe to participants node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'; 'nobody'; 'admins'; 'owners'</td><td>'participants'</td></tr>
-        <tr><td>'Subject Node Subscription'</td><td>Controls who can subscribe to subject node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone' </td><td>'participants'</td></tr>
+        
         <tr><td>'Information Node Subscription'</td><td>Controls who can subscribe to the information node.</td><td>list-single</td><td>'participants'; 'allowed'; 'anyone'</td><td>'participants'</td></tr>
         <tr><td>'Allowed Node Subscription'</td><td>Controls who can subscribe to allowed node.</td><td>list-single</td><td>'participants'; 'allowed';  'nobody'; 'admins'; 'owners' </td><td>'admins'</td></tr>
         <tr><td>'Banned Node Subscription'</td><td>Controls who can subscribe to banned node.</td><td>list-single</td><td>'participants'; 'allowed';  'nobody'; 'admins'; 'owners' </td><td>'admins'</td></tr>
@@ -736,8 +719,6 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
           node='urn:xmpp:mix:nodes:participants'/>
     <item jid='coven@mix.shakespeare.example'
           node='urn:xmpp:mix:nodes:messages'/>
-    <item jid='coven@mix.shakespeare.example'
-          node='urn:xmpp:mix:nodes:subject'/>
     <item jid='coven@mix.shakespeare.example'
           node='urn:xmpp:mix:nodes:config'/>
   </query>
@@ -829,7 +810,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 <section1 topic='Use Cases' anchor='usecases'>
   <section2 topic='Common User Use Cases' anchor='usecases-user'>
     <section3 topic='Joining a Channel' anchor='usecase-user-join'>
-      <p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, presence and subject.
+      <p>A user joins a channel by sending a MIX "join" command. There is no default set of nodes, so user MUST specify the set of nodes to be subscribed to. To achieve the equivalent service to MUC, a user would subscribe to messages, and presence.
          This will lead to the server subscribing the user to each of the requested nodes associated with the channel. The MIX service will also add the user to the participant list by injecting a new item into the "urn:xmpp:mix:nodes:participants" node automatically.
 
       </p>
@@ -906,7 +887,7 @@ This approach  enables flexible support of multiple clients for a MIX channel pa
 ]]></example>
       <p>
         If a user cannot be subscribed to one or more of the requested nodes (e.g., because the node does not exist), but can be subscribed to some the response simply lists the nodes successfully subscribed.    If none of the nodes requested are successfully subscribed to, an error response is sent indicating the reason that the first node requested was not subscribed to.   This response will also include other nodes requested where subscription failed for the same reason. The following response example shows a response to the initial request example where
-the participant is not be subscribed to all nodes associated with the channel (in this case only messages, participants, and subject). The following example is the message from the MIX channel to the user's server, which will be modified and sent to the client.</p>
+the participant is not be subscribed to all nodes associated with the channel (in this case only messages, participants, and information). The following example is the message from the MIX channel to the user's server, which will be modified and sent to the client.</p>
       <example caption="Channel Processes Join With Some Nodes Not Subscribed To"><![CDATA[
 <iq type='result'
     from='hag66@shakespeare.example'
@@ -915,7 +896,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
   <join xmlns='urn:xmpp:mix:0' jid='coven+123456@mix.shakespeare.example'>
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
-    <subscribe node='urn:xmpp:mix:nodes:subject'/>
+    <subscribe node='urn:xmpp:mix:nodes:info'/>
   </join>
 </iq>
 ]]></example>
@@ -1495,35 +1476,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
 </message>
 ]]></example>
     </section3>
-    <section3 topic="Setting the Channel Subject" anchor="set-subject">
+
-      <p>
-       Setting the subject for a channel follows a similar procedure to sending a message.   An XMPP client will send a message setting the subject directly to the MIX channel.   Note that where multiple language variants are used, the subject is repeated and each subject MUST include a language reference.
-      </p>
-      <example caption="User Sets Channel Subject"><![CDATA[
-<message from='hag66@shakespeare.example/pda'
-         to='coven@mix.shakespeare.example'
-         id='92vax143g'
-         type='groupchat'>
-  <subject xml:lang="en">How to use Toads</subject>
-  <subject xml:lang="de">Wie benutzt man Kröten</subject>
-</message>
-]]></example>
-      <p>
-        This message is received by the MIX channel, which will set the Subject Node for the channel, and then distribute the message to participants that are subscribed to the Subject Node, with the message addressed to the participant’s server using the participant's bare JID.
-      </p>
-      <example caption="Channel Reflects New Subject to Participants"><![CDATA[
-<message from='coven+12345@mix.shakespeare.example/678'
-         to='hecate@shakespeare.example'
-         id='77E07BB0-55CF-4BD4-890E-3F7C0E686BBD'
-         type='groupchat'>
-           <subject xml:lang="en">How to use Toads</subject>
-           <subject xml:lang="de">Wie benutzt man Kröten</subject>
-</message>
-]]></example>
-      <p>
-        When a new Participant joins a channel and subscribes to the Subject Node, the channel MUST send to the participant's server (using the participant's bare JID) a message with the current subject.   An XMPP Client MAY directly read the Subject node using &xep0060;.
-      </p>
-    </section3>
     <section3 topic='Telling another User about a Channel' anchor='usecase-user-tell'>
       <p>
         A convenient way to reference another channel is to use &xep0372; which enables the JID of a channel to be shared.  This might be used simply to inform the message recipient about the channel or as mechanism to invite the user to join the channel.   This is useful as an invitation mechanism to a channel that any user can join or where the invitee knows that the user is allowed to join (e.g., because the channel is for all users in an organization).
@@ -1744,7 +1697,7 @@ the participant is not be subscribed to all nodes associated with the channel (i
    </p>
     <section3 topic="Archive of Messages" anchor="use-mam-messages">
       <p>
-        Messages sent to participants MUST be archived by both the MIX channel and by the user's server.   This MUST include messages setting subject and MAY include presence messages.   Correct MIX operation relies on messages being archived.
+        Messages sent to participants MUST be archived by both the MIX channel and by the user's server.   This  MAY include presence messages.   Correct MIX operation relies on messages being archived.
       </p>
     </section3>
     <section3 topic="Retrieving Messages" anchor="use-mam-retrieve">
@@ -2270,7 +2223,6 @@ the participant is not be subscribed to all nodes associated with the channel (i
     <subscribe node='urn:xmpp:mix:nodes:messages'/>
     <subscribe node='urn:xmpp:mix:nodes:presence'/>
     <subscribe node='urn:xmpp:mix:nodes:participants'/>
-    <subscribe node='urn:xmpp:mix:nodes:subject'/>
     <subscribe node='urn:xmpp:mix:nodes:config'/>
   </join>
 </iq>
@@ -2428,10 +2380,14 @@ the participant is not be subscribed to all nodes associated with the channel (i
     </p>
   </section2>
 
+<section2 anchor="not-subject" topic="Subject">
+  <p>&xep0045; provide a Subject capability to enable setting of the current topic of discussion.   The Name and Description attributes provided by MIX enable descriptive information to be associated with a channel.   These attributes can replace Subject in the way it is used in many MUC rooms, but they do not reflect the more limited topic nature of Subject.</p>
+  <p>It is likely that a new XEP to be used with MIX will be written, perhaps using a "Sticky Messages" approach to fulfil the Subject capability using a different approach. </p>
+</section2>
 </section1>
 
 <section1 topic='Internationalization Considerations' anchor='i18n'>
-  <p>MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the subject of a  MIX channel and name and description information.   These strings MAY have language set using an xml:lang attribute, and multiple values MAY be set provided that each one is distinguished using xml:lang.
+  <p>MIX allows specification of a number of human readable strings associated with a MIX channel, in particular the name and description information of a  MIX channel.   These strings MAY have language set using an xml:lang attribute, and multiple values MAY be set provided that each one is distinguished using xml:lang.
   </p>
 
   <p>Nicknames SHOULD be normalized using the "nickname" profile of the PRECIS OpaqueString class, as defined in &rfc7700;. </p>