3066 to 4646

git-svn-id: file:///home/ksmith/gitmigration/svn/xmpp/trunk@184 4b5297f7-1745-476d-ba37-a9c6900126ab

xep-0045.xml

@@ -385,7 +385,7 @@
   </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 community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" protocol provided a minimal feature set for chat rooms but was rather limited in scope. This specification 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. These extensions are implemented using protocol elements qualified by the 'http://jabber.org/protocol/muc' namespace (and the #owner, #admin, and #user fragments on the main namespace URI).</p>
+  <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 community developed and implemented a basic groupchat protocol as long ago as 1999. This "groupchat 1.0" 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 community or are familiar from existing text-based conference environments outside of Jabber (e.g., Internet Relay Chat as defined in &rfc1459; and its successors).</p>
@@ -397,6 +397,7 @@
     <li>Security and encryption at the level of a room or service</li>
     <li>Advanced features such as attaching files to a room, integrating whiteboards, and interfacing with audio chat services</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 Jabber client and component developers alike. Future specifications may of course address the topics mentioned above.</p>
 </section1>
@@ -436,6 +437,7 @@
     <li>moderated or unmoderated</li>
     <li>non-anonymous or 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'>
@@ -1513,7 +1515,8 @@
 </presence>
     ]]></example>
     <p>Normal presence stanza generation rules apply as defined in &xmppim;, so that if the user sends a general unavailable presence stanza, the user's server will broadcast that stanza to the &ROOMJID; to which the user's client has sent directed presence.</p>
-    <p>If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.</p>
+    <p>It is possible that a user may not be able to gracefully exit the room by sending unavailable presence directly to the room. If the user goes offline without sending unavailable presence, the user's server is responsible for sending unavailable presence on behalf of the user (in accordance with <cite>RFC 3921</cite>). If the user's server goes offline or connectivity is lost between the user's server and the MUC service to which the user is connected (e.g., in federated communications), the MUC service is responsible for monitoring error stanzas it receives in order to determine if the user has gone offline. If the MUC service determines that the user has gone offline, it must treat the user as if the user had itself sent unavailable presence.</p>
+    <p>Note: If the room is not persistent and this occupant is the last to exit, the service is responsible for destroying the room.</p>
   </section2>
   <section2 topic='Changing Nickname' anchor='changenick'>
     <p>A common feature of multi-user chat rooms is the ability for an occupant to change his or her nickname within the room. In MUC this is done by sending updated presence information to the room, specifically by sending presence to a new room JID in the same room (changing only the resource identifier in the room JID).</p>
@@ -1600,7 +1603,7 @@
   </error>
 </presence>
     ]]></example>
-    <p>However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the <link url='enter-conflict'>Nickname Conflict</link> section of this document for details.</p>
+    <p>However, if the bare JID (&BAREJID;) of the present occupant matches the bare JID of the user seeking to change his or her nickname, then the service MAY allow the nickname change. See the <link url='#enter-conflict'>Nickname Conflict</link> section of this document for details.</p>
     <p>If the user attempts to change his or her room nickname but room nicknames are "locked down", the service MUST deny the nickname change request and return a presence stanza of type "error" specifying a &notacceptable; error condition:</p>
     <example caption='Service Denies Nickname Change Because Roomnicks Are Locked Down'><![CDATA[
 <presence
@@ -4724,7 +4727,7 @@ xmpp:darkcave@macbeth.shakespeare.lit?invite;jid=hecate@shakespeare.lit;password
       <li><p>A MUC service MAY choose to make available a special in-room resource that provides an interface to administrative functionality (e.g., a "user" named "ChatBot"), which occupants could interact with directly, thus enabling admins to type <tt>'/command parameter'</tt> in a private message to that "user". Obviously this kind of implementation would require the service to add a 'ChatBot' user to the room when it is created, and to prevent any occupant from having the nickname 'ChatBot' in the room. This might be difficult to ensure in some implementations or deployments. In any case, any such interface is OPTIONAL.</p></li>
       <li><p>A MUC service SHOULD remove a user if the service receives a delivery-related error in relation to a stanza it has previously sent to the user (remote server unreachable, user not found, etc.).</p></li>
       <li><p>A MUC service MAY choose to discard extended presence information that is attached to a &PRESENCE; stanza before reflecting the presence change to the occupants of a room. That is, an implementation MAY choose to reflect only the &lt;show/&gt;, &lt;status/&gt;, and &lt;priority/&gt; child elements of the presence element as specified in the XML schema for the 'jabber:client' namespace, with the result that presence "changes" in extended namespaces (e.g., gabber:x:music:info) are not passed through to occupants. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
-      <li><p>A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
+      <li><p>A MUC service MAY choose to discard extended information attached to &MESSAGE; stanzas before reflecting the message to the occupants of a room. An example of such extended information is the lightweight text markup specified by &xep0071;. If a service prohibits certain extended namespaces, it SHOULD provide a description of allowable traffic at the well-known Service Discovery node 'http://jabber.org/protocol/muc#traffic' as described in the <link url='#impl-service-traffic'>Allowable Traffic</link> section of this document.</p></li>
       <li><p>A MUC service MAY choose to "lock down" room nicknames (e.g., hardcoding the room nickname to the bare JID of the occupant). If so, the service MUST treat the locked down nickname as a reserved room nickname and MUST support the protocol specified in the <link url='#reservednick'>Discovering Reserved Room Nickname</link> section of this document.</p></li> 
     </ol>
     <section3 topic='Allowable Traffic' anchor='impl-service-traffic'>

xep-0071.xml

@@ -216,7 +216,7 @@
   <p>These three aspects are defined in the three document sections that follow.</p>
 </section1>
 <section1 topic='Wrapper Element' anchor='wrapper'>
-  <p>The root element for including XHTML content within XMPP stanzas is &lt;html/&gt;. This element is qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. From the perspective of XMPP, it functions as an XMPP extension element; from the perspective of XHTML, it functions as a wrapper for XHTML 1.0 content qualified by the 'http://www.w3.org/1999/xhtml' namespace. Such XHTML content MUST be contained in one or more &lt;body/&gt; elements qualified by the 'http://www.w3.org/1999/xhtml' namespace and MUST conform to the XHTML-IM Integration Set defined in the following section. If more than one &lt;body/&gt; element is included in the &lt;html/&gt; wrapper element, each &lt;body/&gt; element MUST possess an 'xml:lang' attribute with a distinct value, where the value of that attribute MUST adhere to the rules defined in &rfc3066;. A formal definition of the &lt;html/&gt; element is provided in the <link url="#schemas-wrapper">XHTML-IM Wrapper Schema</link>.</p>
+  <p>The root element for including XHTML content within XMPP stanzas is &lt;html/&gt;. This element is qualified by the 'http://jabber.org/protocol/xhtml-im' namespace. From the perspective of XMPP, it functions as an XMPP extension element; from the perspective of XHTML, it functions as a wrapper for XHTML 1.0 content qualified by the 'http://www.w3.org/1999/xhtml' namespace. Such XHTML content MUST be contained in one or more &lt;body/&gt; elements qualified by the 'http://www.w3.org/1999/xhtml' namespace and MUST conform to the XHTML-IM Integration Set defined in the following section. If more than one &lt;body/&gt; element is included in the &lt;html/&gt; wrapper element, each &lt;body/&gt; element MUST possess an 'xml:lang' attribute with a distinct value, where the value of that attribute MUST adhere to the rules defined in &rfc4646;. A formal definition of the &lt;html/&gt; element is provided in the <link url="#schemas-wrapper">XHTML-IM Wrapper Schema</link>.</p>
   <p>Note: The XHTML &lt;body/&gt; element is not to be confused with the XMPP &lt;body/&gt; element, which is a child of a &MESSAGE; stanza and is qualified by the 'jabber:client' or 'jabber:server' namespace as described in &xmppim;. The &lt;html/&gt; wrapper element is intended for inclusion only as a direct child element of the XMPP &MESSAGE; stanza and only in order to specify a marked-up version of the message &BODY; element or elements, but MAY be included elsewhere in accordance with the "extended namespace" rules defined in the <cite>XMPP IM</cite> specification.</p>
   <p>Until and unless (1) additional integration sets are defined and (2) mechanisms are specified for discovering or negotiating which integration sets are supported, the XHTML markup contained within the &lt;html/&gt; wrapper element MUST NOT include elements and attributes that are not part of the XHTML-IM Integration Set defined in the following section, and any such elements and attributes MUST be ignored if received (where the meaning of "ignore" is defined by the conformance requirements of <cite>Modularization of XHTML</cite>, as summarized in the <link url="#w3c-conformance">User Agent Conformance</link> section of this document).</p>
 </section1>

xep-0085.xml

@@ -234,7 +234,7 @@ INACTIVE <--> ACTIVE <--> COMPOSING
       <li>If the Contact replies to the initial content message but does not include a chat state notification extension, the User MUST NOT send subsequent chat state notifications to the Contact.</li>
       <li>If the Contact replies to the initial content message and includes an &lt;active/&gt; notification (or sends a standalone notification to the User), the User and Contact SHOULD send subsequent notifications for supported chat states (as specified in the next subsection) by including an &lt;active/&gt; notification in each content message and sending standalone notifications for the chat states they support (at a minimum, the &lt;composing/&gt; state).</li>
     </ol>
-    <p>The foregoing rules imply that the sending of chat state notifications is bidirectional (i.e., both User and Contact will either send or not send chat state notifications) rather than unidirectional (i.e., one of the conversation partners will send chat state notifications but the other will not); this is intentional.</p>
+    <p>The foregoing rules imply that the sending of chat state notifications is bidirectional (i.e., both User and Contact will either send or not send chat state notifications) rather than unidirectional (i.e., one of the conversation partners will send chat state notifications but the other will not); this is by design.</p>
   </section2>
   <section2 topic='Support Requirements' anchor='bizrules-support'>
     <table caption='Requirements for Supporting Each Chat State'>

xep-0152.xml

@@ -67,7 +67,7 @@
 </reach>
   ]]></example>
   <p>When publishing reachability addresses, the &lt;reach/&gt; element MUST contain at least one &lt;addr/&gt; element. Each &lt;addr/&gt; element MUST possess a 'uri' attribute, whose value MUST be the Uniform Resource Identifier (&rfc3986;) or Internationalized Resource Identifier (&rfc3987;) of an alternate communications method for reaching the user.</p>
-  <p>The &lt;addr/&gt; element MAY contain one or more &lt;desc/&gt; children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc3066; (although the default language MAY be specified at the stanza level; see Section 9.1.5 of &rfc3920;). In order to preserve bandwidth, the &lt;desc/&gt; element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using personal eventing.</p>
+  <p>The &lt;addr/&gt; element MAY contain one or more &lt;desc/&gt; children whose XML character data is a natural-language description of the address; this element SHOULD possess an 'xml:lang' attribute whose value is a language tag that conforms to &rfc4646; (although the default language MAY be specified at the stanza level; see Section 9.1.5 of &rfc3920;). In order to preserve bandwidth, the &lt;desc/&gt; element SHOULD NOT be included when sending reachbility data via presence broadcast, but MAY be included when using personal eventing.</p>
   <example caption="Reachability Addresses With Descriptions"><![CDATA[
 <reach xmlns='http://jabber.org/protocol/reach'>
   <addr uri='tel:+1-303-555-1212'>

xep-0154.xml

@@ -1521,7 +1521,7 @@
     </section3>
     <section3 topic='Languages Known Less Well' anchor='languages_lesswell'>
       <p>Some people know more than one language, but less than well (e.g., the person may not be able to speak fluently). The definition of "less well" is left to the user.</p>
-      <p>The value of this field MUST be an abbreviation for a language as specified in &rfc3066;.</p>
+      <p>The value of this field MUST be an abbreviation for a language as specified in &rfc4646;.</p>
       <p>The Data Forms field that represents a language known less that well is "languages_lesswell".</p>
       <example caption='Languages Known Less than Well'><![CDATA[
 <field var='languages_lesswell'>
@@ -1533,7 +1533,7 @@
     </section3>
     <section3 topic='Languages Known Well' anchor='languages_well'>
       <p>Everyone knows at least one language well (e.g., they are able to speak or write the language with a fair degree of fluency). Determination of whether someone knows a language "well" or "fluently" is left to the user.</p>
-      <p>The value of this field MUST be an abbreviation for a language as specified in <cite>RFC 3066</cite>.</p>
+      <p>The value of this field MUST be an abbreviation for a language as specified in <cite>RFC 4646</cite>.</p>
       <p>The Data Forms field that represents a language known well is "languages_well".</p>
       <p>This field maps to:</p>
       <ul>

xep-0177.xml

@@ -111,7 +111,6 @@
       </transport>
     </content>
   </jingle>
-  </jingle>
 </iq>
     ]]></example>
     <p>The initiator MUST then acknowledge acceptance by returning an IQ result (or return a standard XMPP error).</p>

xep-0183.xml

@@ -73,13 +73,13 @@
       <li>The 'time' attribute is used for diagnostics; the allowable values are "past", "present", and "future".</li>
     </ul>
   </section2>
-  <section2 topic='Target Entity Response' anchor='protocol-response'>
+  <section2 topic='Receiver Response' anchor='protocol-response'>
-    <p>As described in <cite>XEP-0166</cite>, to provisionally accept the session initiation request, the target entity returns an IQ-result:</p>
+    <p>As described in <cite>XEP-0166</cite>, to provisionally accept the session initiation request, the receiver returns an IQ-result:</p>
-    <example caption="Target Entity Provisionally Accepts the Session Request"><![CDATA[
+    <example caption="Receiver Provisionally Accepts the Session Request"><![CDATA[
 <iq type='result' from='psychic@example.net/spiritworld' to='medium@example.com/seance' id='jingle1'/>
     ]]></example>
-    <p>To definitively accept the telepathy transport method, the target entity MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.</p>
+    <p>To definitively accept the telepathy transport method, the receiver MUST send a &JINGLE; element with an action of 'transport-accept', specifying the transport method desired.</p>
-    <example caption="Target Entity Accepts the Telepathy Transport Method"><![CDATA[
+    <example caption="Receiver Accepts the Telepathy Transport Method"><![CDATA[
 <iq type='set' from='psychic@example.net/spiritworld' to='medium@example.com/seance' id='jingle2'/>
   <jingle xmlns='http://jabber.org/protocol/jingle' 
           action='transport-accept' 
@@ -91,12 +91,12 @@
   </jingle>
 </iq>
     ]]></example>
-    <p>The initiating entity then acknowledges the target entity's acceptance:</p>
+    <p>The initiating entity then acknowledges the receiver's acceptance:</p>
     <example caption="Initiating Entity Acknowledges Definitive Acceptance"><![CDATA[
 <iq from='medium@example.com/seance' to='psychic@example.net/spiritworld' id='jingle2' type='result'>
     ]]></example>
-    <p>Now the initiating entity and target entity can begin sending appropriate psychical media over the negotiated ESP stream.</p>
+    <p>Now the initiating entity and receiver can begin sending appropriate psychical media over the negotiated ESP stream.</p>
-    <p>In the event that the target entity cannot establish a channel, it SHOULD terminate the session (see <cite>XEP-0176</cite> or <cite>XEP-0177</cite> for examples).</p>
+    <p>In the event that the receiver cannot establish a channel, it SHOULD terminate the session (see <cite>XEP-0176</cite> or <cite>XEP-0177</cite> for examples).</p>
   </section2>
   <section2 topic='Informational Messages' anchor='protocol-info'>
     <p>Because the informational message payloads specific to the telepathy transport method cannot be tied down to the arbitrary conventions of XML syntax, a &lt;message/&gt; element qualified by the 'http://jabber.org/protocol/info/telepathy' namespace may include any character data that either party feels like communicating.</p>

xep.ent

@@ -395,6 +395,7 @@
 <!ENTITY rfc4505 "<span class='ref'>RFC 4505</span> <note>RFC 4505: The SASL ANONYMOUS Mechanism &lt;<link url='http://www.ietf.org/rfc/rfc4505.txt'>http://www.ietf.org/rfc/rfc4505.txt</link>&gt;.</note>" >
 <!ENTITY rfc4566 "<span class='ref'>RFC 4566</span> <note>RFC 4566: SDP: Session Description Protocol &lt;<link url='http://www.ietf.org/rfc/rfc4566.txt'>http://www.ietf.org/rfc/rfc4566.txt</link>&gt;.</note>" >
 <!ENTITY rfc4622 "<span class='ref'>RFC 4622</span> <note>RFC 4622: Internationalized Resource Identifiers (IRIs) and Uniform Resource Identifiers (URIs) for the Extensible Messaging and Presence Protocol (XMPP) &lt;<link url='http://www.ietf.org/rfc/rfc4622.txt'>http://www.ietf.org/rfc/rfc4622.txt</link>&gt;.</note>" >
+<!ENTITY rfc4646 "<span class='ref'>RFC 4646</span> <note>RFC 4646: Tags for Identifying Languages &lt;<link url='http://www.ietf.org/rfc/rfc4646.txt'>http://www.ietf.org/rfc/rfc4646.txt</link>&gt;.</note>" >
 
 <!-- Internet-Drafts -->